-
Notifications
You must be signed in to change notification settings - Fork 3
Factor out the time aggregation function, stop special-casing utility. #234
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
base: main
Are you sure you want to change the base?
Conversation
Instead of wrapping each function to accept an internal_regime_params dict and extracting parameters at call time, use dags.signature.rename_arguments() to qualify parameter names with function prefixes (e.g., risk_aversion becomes utility__risk_aversion). This makes the parameter flow explicit and removes the internal_regime_params indirection from all function signatures. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…at_regime_params. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ParamsTemplate. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…s Callable in result.py. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…mstances than REGIME_SEPARATOR. Some small improvements.
255217d to
88bc936
Compare
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
88bc936 to
be2b079
Compare
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
hmgaudecker
left a comment
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.
Autoreview.
|
timmens
left a comment
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.
Very very nice PR! I like the change a lot.
My main comment is that I think we should rename H for the user. An example could be aggregator or time_aggregator. All other user-facing argument or attribute names are expressive and not related to the math notation, so I would not expect it here.
Why I added utility as its own attribute
While I do think that in the current state of PyLCM it makes sense to add utility and the time aggregator in the functions dictionary, here are some of my thoughts on why I pulled utility out, in case we want to do that in the future again:
- Each attribute of the
Regimeclass should correspond to an object that is related to the Economic problem. Utility is such an object, auxiliary functions are not. - Using the
functionsdictionary makes our model specifications much more readable, but it is not necessary in principle. A user could also just write a single utility function. - For objects like the time aggregator, typing is easier if it would be a Regime attribute.
Nevertheless, the fact that with this PR we can remove a lot of special cases, and the parameter processing works smoothly for all functions (also for the meta-level functions like the time aggregator) is the big reason why your implementation wins right now.
|
Agreed! I had that The only thing that kept me was the thought that for the next level (truly fixing #174, including cases like hyperbolic discounting), we'll have to make a bunch of the I don't have a strong opinion -- what do you think? Thanks for the explainer re utility! |
H(utility, continuation_value; params), but no more complex forms.Regime.