-
-
Notifications
You must be signed in to change notification settings - Fork 198
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
[WIP] Abstract Variables/Symbols #1308
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## master #1308 +/- ##
==========================================
- Coverage 72.55% 72.16% -0.40%
==========================================
Files 78 79 +1
Lines 13009 13080 +71
==========================================
Hits 9439 9439
- Misses 3570 3641 +71
☔ View full report in Codecov by Sentry. |
Having trouble setting tests up but this works locally. |
@ingydotnet here I am starting the work of building the abstract objects |
Test failures may be due to Python versions (3.8, 3.9, etc.). A lot of these more advanced language features are relatively recent. |
name: m | ||
short_name: money | ||
long_name: market resources | ||
latex_repr: \mNrm |
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 know how you're imagining using the Latex representation.
But my preference would be to not include it in the PR unless you have some demonstration of how it works ready.
4 different ways to name something for a quick demo seems like a lot....
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.
For now these are filler, I want to throw any non-required keys into an attributes dictionary.
- !Action | ||
name: c | ||
short_name: consumption | ||
long_name: consumption |
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.
Are these fields optional? Can one spill over to the others as a default?
Basically, how can we make these config files lighter weight?
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.
These are optional, only required is name.
long_name: market resources | ||
latex_repr: \mNrm | ||
- !State | ||
name: &name stigma |
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 don't understand what the ampersands are doing here.
Maybe document that?
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.
ampersands are aliases, since one of the states is also a control and a post-state. I will document this more as I make more progress.
post_states: !PostStateSpace | ||
variables: | ||
- !PostState | ||
name: a |
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 like you've repeated the post_states block twice in this file?
Not sure how @mnwhite feels, but maybe we don't need to draw a firm distinction between states and post states like this.
Or the labels could be inside the variable, not part of the document structure.
Compare:
var_type_1:
variables:
- !VarTypeClass1
details
var_type_2:
variables:
- !VarTypeClass2
details
with
variables:
- !VarTypeClass1
details
- !VarTypeClass2
details
The latter is same information, but fewer lines.
self.shocks = self.variables | ||
|
||
|
||
def make_state_array( |
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.
Is this method duplicated?
import yaml | ||
|
||
import HARK.abstract.variables | ||
|
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.
A test case showing how this data structure could be used in practice would go a long way.
I think this is a cool demonstration of how PyYAML can be leveraged to make model configuration files in YAML without a custom parser. The tricky part, as we know, is function definitions. |
yep, this might have to be a feature for the future, just getting some initial work done on it |
Yes! I was just talking to one of the creators of YAML who was telling me about this https://github.com/yaml/yamlscript |
Mind blown emoji. One more thing: I'd be keen to see how you would initialize a distribution for a shock directly from YAML. |
|
||
|
||
@dataclass | ||
class Auxiliary(Variable): |
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 agree with Chris that 'auxiliary' is more like a macro.
I wouldn't use 'auxiliary' here, though it makes sense to have this sort of object.
|
||
|
||
@dataclass | ||
class Variable(YAMLObject): |
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.
Is there a way to initialize Variables without parsing them from a YAML file?
I.e., a pure python way to create variables?
I'm a little wary of tying the model objects too tightly to the serial format because it can make it tricky to interoperate with other python libraries.
@MridulS thank you for fixing the checks! Might you be able to help me with the failing test? I'm not sure why |
Co-authored-by: Mridul Seth <mail@mriduls.com>
Please ensure your pull request adheres to the following guidelines: