-
Notifications
You must be signed in to change notification settings - Fork 57
Changes to definitions of named gauge optimization suites, resolve (unnecessary) warnings, robustify report generation #622
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
Changes from all commits
05a7a79
59a8796
7f5e535
e684807
cdc21f7
2bbeab9
394c25e
0f77d16
4956cdf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The overwhelming majority of changes to this file are in
All other changes to _update_gaugeopt_dict_from_suitename amount to readability. Here are notes I made while convincing myself of this Details for the morbidly curiousI'll start with notes confined entirely to _update_gaugeopt_dict_from_suitename.
The dicts that get constructed in _update_gaugeopt_dict_from_suitename get passed as kwargs in call(s) to gaugeopt_to_target. So, understanding the consequences of my changes to _update_gaugeopt_dict_from_suitename amounts to understanding how gaugeopt_to_target behaves when provided with kwargs of the kind constructed in lines 1009 -- 1062 of gst.py.
Now let's look back at _update_gaugeopt_dict_from_suitename. From the behavior outlined above, we see that a change to the to_type key of the convert_to dict has no effect on the gauge group used in gauge optimization. However, I've opted to also change convert_to's "set_default_gaugegroup" key to False, since that makes our intent clearer. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Awesome work, thank you for tracking this down and for the detailed summary! |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Style and "hygiene." |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Changes accidentally left out of PR #615. |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This resolves a deprecation warning. |
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.
The branching was unnecessary, since
jac=None
is the default value forjac
in both this function and the scipy function we're calling.