-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hparams as dict #1029
hparams as dict #1029
Conversation
Hello @Borda! Thanks for updating this PR.
Comment last updated at 2020-03-04 14:26:43 UTC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Maybe we shouldn't have fixed the doc around this haha.
well, unless we define the |
Correct me if I'm wrong. This does NOT solve #977. The discussion there is not over. As far as I can see this PR does not address the issue we have with restoring the hparams. This pr also adds other changes unrelated to hparams, why? |
pytorch_lightning/core/lightning.py
Outdated
hparams = Namespace(**self._hparams) | ||
return hparams | ||
|
||
def set_hparams(self, params: Union[Dict[str, Any], Namespace]): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setters in python should be done with @hparams.setter
decorator, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you in decorator define types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hparams.setter
def hparams(self, params: Union[Dict[str, Any], Namespace]):
self._hparams = params
This should work. However, it does not enforce the types. The user can still pass in whatever it wants.
yeah, sorry, made is WIP, I have added somment to the original thread, could you check it pls... |
@Borda I see a small edge case (maybe).
user trains model ... |
great job guys! let's wrap this up in the next few hours so we can do the release. this is the last PR holding this up |
@awaelchli I see a solution to have
|
Yes, that's one way. It would also mean from now on self.hparams is always going to be a Namespace, and it would break exising code bases where they had a dict or something else. Is this acceptable? |
@williamFalcon @awaelchli in checkpoint the |
@williamFalcon Yes there should probably a save and load test with dict. |
this code forces a load as namespace. if the user model defined a dictionary then it would break no? because the user would access hparams[“arg”] but since we always force a namespace that would crash? |
@williamFalcon if you want that behaviour I see no way around pickeling the whole hparams object or saving the type with it as I suggested in #943 . Otherwise at load time we have no way of telling the type the user chose. |
checkpoint['hparams'] = vars(model.hparams) | ||
is_namespace = isinstance(model.hparams, Namespace) | ||
checkpoint['hparams'] = vars(model.hparams) if is_namespace else model.hparams | ||
checkpont['hparams_type'] = 'namespaces' if is_namespace else 'dict' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@awaelchli @Borda fixed it... now need to fix load
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how does that address your concern about hparams[".." ] access? load_from_checkpoint will pass a Namespace to Lightningmodule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok nvm :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well I would rather stay with the fixed interface - hparams
as Namespace property and setter
* hparams as dict * hparams as dict * fixing * fixing * fixing * fixing * typing * typing * chnagelog * update set hparams * use setter * simplify * chnagelog * imports * pylint * typing * Update training_io.py * Update training_io.py * Update lightning.py * Update test_trainer.py * Update __init__.py * Update base.py * Update utils.py * Update test_trainer.py * Update training_io.py * Update test_trainer.py * Update test_trainer.py * Update test_trainer.py * Update test_trainer.py * Update callback_config.py * Update callback_config.py * Update test_trainer.py Co-authored-by: William Falcon <waf2107@columbia.edu>
What does this PR do?
Fixes #977
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃