Skip to content
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

Complete deprecation of HARK.core.Solution #481

Closed
sbenthall opened this issue Jan 31, 2020 · 14 comments
Closed

Complete deprecation of HARK.core.Solution #481

sbenthall opened this issue Jan 31, 2020 · 14 comments
Assignees
Milestone

Comments

@sbenthall
Copy link
Contributor

Trying to work through the core logic of HARK...it looks like there is a deprecated Solution class, but that there is some dead code still lying around because of it.

HARK/HARK/core.py

Lines 156 to 163 in eb8d1a6

class Solution(HARKobject):
'''
A superclass for representing the "solution" to a single period problem in a
dynamic microeconomic model.
NOTE: This can be deprecated now that HARKobject exists, but this requires
replacing each instance of Solution with HARKobject in the other modules.
'''

This ticket is for completing the deprecation of HARK.core.Solution

@mnwhite
Copy link
Contributor

mnwhite commented Jan 31, 2020 via email

@llorracc
Copy link
Collaborator

@sbenthall are you joining the Zoom conv going on right now

@sbenthall
Copy link
Contributor Author

@mnwhite That's interesting. I'm trying to understand the architecture of the core solution code.
This relates to #482

It looks like the class ConsumerSolution inherits from Solution.

class ConsumerSolution(Solution):

This class has many parameters that are specific to the model which could be abstracted away in a more general class.

For example, rather than hard-coding the consumption function, taking market resources as input, as cFunc, in general MDP's support a "policy" that maps* from state variables to actions.

I think it would be smart to back up as much general logic to more abstract classes, if possible. I'm still trying to work out to what degree that's possible.

@mnwhite
Copy link
Contributor

mnwhite commented Jan 31, 2020 via email

@sbenthall
Copy link
Contributor Author

Ok, gotcha. I'm glad to hear this is the intended direction.

I may have the bandwidth to work towards this. I think it's going to be necessary for any kind of significant integration with Dolo.

As you say, it may require a big rewrite to really effect this change. But I wonder if there's any more incremental steps towards it. I'll see what I can do.

@llorracc
Copy link
Collaborator

llorracc commented Jan 31, 2020 via email

@sbenthall
Copy link
Contributor Author

Is DolARK effectively HARK 2.0?
In other words, rather than trying to patch HARK, would it be better to work on expanding the functionality of DolARK, as indicated by the chimeras?

@llorracc
Copy link
Collaborator

llorracc commented Feb 1, 2020 via email

@mnwhite
Copy link
Contributor

mnwhite commented Feb 1, 2020 via email

@llorracc
Copy link
Collaborator

llorracc commented Feb 1, 2020 via email

@mnwhite
Copy link
Contributor

mnwhite commented Feb 1, 2020 via email

@sbenthall
Copy link
Contributor Author

Is there a document anywhere where you lay out the anticipated design for HARK 2.0 with integrated DolARK? I believe I have a pretty sound and sympatico idea of what the different functionalities are that need to fit together to make software like this work well. Here and elsewhere I seem to be getting tripped up on choices that you've made about how to carve that functionality up into different repositories/packages.

If there is no such design document, I can try to write one based on these conversations and run it by you.

As the main substantive issues left for how to link DolARK and HARK in the combined "2.0 vision", I'm thinking:

  • DolARK will have a parser that reads in model configuration files. But it will have to parse these into a (generic) model class. Will this model class be Dolo's Model class, be a new class in DolARK, or a new class in HARK?
  • Generic solvers will operate on this generic model class. Will these generic algorithms be in DolARK or in HARK?

I'm talking about the ideal design we want to get to, I understand HARK's current limitations.

@sbenthall
Copy link
Contributor Author

These are my notes on a 2.0 plan so far.

https://github.com/econ-ark/HARK/wiki/Towards-2.0

@sbenthall
Copy link
Contributor Author

Closed with #772

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants