-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add Lbfgs #12
Add Lbfgs #12
Conversation
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.
Looks good overall, the main thing I'd like to see changed is changing --use_lbfgs
to --optimizer
with two string options. But maybe Walter has a different opinion.
elk/utils_evaluation/parser.py
Outdated
parser.add_argument("--seed", type=int, default=0) | ||
parser.add_argument( | ||
"--model_device", | ||
type=str, | ||
default="cuda", | ||
help="What device to load the model onto: CPU or GPU or MPS.", | ||
) | ||
parser.add_argument( | ||
"--use_lbfgs", action="store_true", help="Use lbfgs optimizer to train CCS." |
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.
I propose --optimizer
with choices=("adam", "lbfgs")
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.
I used an enum for type safety. Literal["adam", "lbfgs"] can't be used in argparse.
But maybe you think it's better to use str and then assert that the optimizer is correct?
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.
You can use choices=("adam", "lbfgs")
in argparse
. I tend not to use enums because they're verbose— you have to type Optimizer.adam
instead of just "adam"
. For now I'd recommend just using strings + an assert
statement. But maybe @lauritowal disagrees.
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.
Done. Also, the assert is done by argparse in the parser, and I had already an assert in the training code for ccs, so I guess no additional assert is needed.
for more information, see https://pre-commit.ci
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.
It looks mostly good to me. Just as a small note: Next time, it would be maybe cleaner to create two pull-requests. One for the cleaning up and one for the actual feature / fix you want to add
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.
LGTM
Fix #1