Undocumented AgentType.solution property, with awkward interface

[sbenthall]

A key property of AgentType, referred to in all the tutorial materials, is AgentType.solution.

This property is not initialized when a subclass of AgentType is created.
It is not documented.

Rather, it is set when the class's solve() method is ran.

HARK/HARK/core.py

Line 385 in eb8d1a6

self.solution = solveAgent(self, verbose) # Solve the model by backward induction

Maybe because it isn't well documented, the interface for accessing this solution is a bit complicated and obscure. This seems to be typical of the coding pattern to inspect a model solution:

print('Linear perfect foresight consumption function:')
mMin = PFexample.solution[0].mNrmMin
plotFuncs(PFexample.solution[0].cFunc,mMin,mMin+10.)

What type is solution[0]? There's no way to know from the documentation.

Documenting how this works will make HARK more usable.
It may also reveal a way to make this part of the interface smoother and more idiomatic for scientific python.

[sbenthall]

It looks like one reason why this feature remains undocumented is because there's a workaround method defined for some subclasses, unpackcFunc()

https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsIndShockModel.py#L1683-L1702

With a little work, it should be possible to 'unpack' the solution automatically without an additional method call.

[llorracc]

I think we should generalize "unpackcFunc" to something that unpacks ALL the created functions ("vFunc, vPFunc" etc); and furthermore, unless it imposes serious computational burden, think the funcs should be unpacked automatically and without user having to know that they have to do it.

…

On Sat, Feb 15, 2020 at 9:11 PM Sebastian Benthall ***@***.***> wrote: It looks like one reason why this feature remains undocumented is because there's a workaround method defined for some subclasses, unpackcFunc() — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=AAKCK73DPTIFGTMENVNNWLDRDBD6BA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK77YQECL3MSVAWXYL5DRDBD6BANCNFSM4KOIOCSA> .

-- - Chris Carroll

[mnwhite]

Yeah, and that method should be generalized to unpack(), so that all current cases of unpackcFunc() would become unpack('cFunc').

…

On Sat, Feb 15, 2020 at 3:11 PM Sebastian Benthall ***@***.***> wrote: It looks like one reason why this feature remains undocumented is because there's a workaround method defined for some subclasses, unpackcFunc() — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=ADKRAFOPD4LAC5GVCS5H3NTRDBD6DA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFPJQPMKGKCD2FDLC7LRDBD6DANCNFSM4KOIOCSA> .

[mnwhite]

Unpacking all of the relevant solution objects is fine, we'll just need each class to manually list these out. The unpack method can simply be called in postSolve(). On Sat, Feb 15, 2020 at 3:17 PM Christopher Llorracc Carroll < [email protected]> wrote:

…

I think we should generalize "unpackcFunc" to something that unpacks ALL the created functions ("vFunc, vPFunc" etc); and furthermore, unless it imposes serious computational burden, think the funcs should be unpacked automatically and without user having to know that they have to do it. On Sat, Feb 15, 2020 at 9:11 PM Sebastian Benthall < ***@***.***> wrote: > It looks like one reason why this feature remains undocumented is because > there's a workaround method defined for some subclasses, unpackcFunc() > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #482?email_source=notifications&email_token=AAKCK73DPTIFGTMENVNNWLDRDBD6BA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAKCK77YQECL3MSVAWXYL5DRDBD6BANCNFSM4KOIOCSA > > . > -- - Chris Carroll — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=ADKRAFJIEXKQCDVL7E5BTPTRDBEWDA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WCNA#issuecomment-586637620>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFJFL5M5UWWM4GKW6DTRDBEWDANCNFSM4KOIOCSA> .

[llorracc]

I guess it would be hard to write something that could just inspect the object and find and unpack all of the functions defined by it? Seems like maybe if we tagged each created function with a label like 'unpackable' that would be better than trying to list the functions that could be unpacked. On Sat, Feb 15, 2020 at 9:20 PM Matthew N. White <[email protected]> wrote:

…

Unpacking all of the relevant solution objects is fine, we'll just need each class to manually list these out. The unpack method can simply be called in postSolve(). On Sat, Feb 15, 2020 at 3:17 PM Christopher Llorracc Carroll < ***@***.***> wrote: > I think we should generalize "unpackcFunc" to something that unpacks ALL > the created functions ("vFunc, vPFunc" etc); and furthermore, unless it > imposes serious computational burden, think the funcs should be unpacked > automatically and without user having to know that they have to do it. > > > > On Sat, Feb 15, 2020 at 9:11 PM Sebastian Benthall < > ***@***.***> > wrote: > > > It looks like one reason why this feature remains undocumented is because > > there's a workaround method defined for some subclasses, unpackcFunc() > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > < > #482?email_source=notifications&email_token=AAKCK73DPTIFGTMENVNNWLDRDBD6BA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132 > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AAKCK77YQECL3MSVAWXYL5DRDBD6BANCNFSM4KOIOCSA > > > > . > > > > > -- > - Chris Carroll > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #482?email_source=notifications&email_token=ADKRAFJIEXKQCDVL7E5BTPTRDBEWDA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WCNA#issuecomment-586637620 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADKRAFJFL5M5UWWM4GKW6DTRDBEWDANCNFSM4KOIOCSA > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=AAKCK75JVYQX3DOGGLCPXDTRDBFATA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WEGQ#issuecomment-586637850>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK74OQ2VHHG3SGIE2HP3RDBFATANCNFSM4KOIOCSA> .

-- - Chris Carroll

[mnwhite]

There aren't really "tags" in Python, other than giving every single instance of a particular object a dummy attribute. But that would be a waste of memory. Why is it so bad for the model creator to write one line explicitly naming what should be unpacked? Isn't that the most obvious place someone would look to see what's being unpacked-- where it's actually being done-- rather than go back and look through the entire solution code to see which objects get that "tag"? On Sat, Feb 15, 2020 at 3:27 PM Christopher Llorracc Carroll < [email protected]> wrote:

…

I guess it would be hard to write something that could just inspect the object and find and unpack all of the functions defined by it? Seems like maybe if we tagged each created function with a label like 'unpackable' that would be better than trying to list the functions that could be unpacked. On Sat, Feb 15, 2020 at 9:20 PM Matthew N. White ***@***.*** > wrote: > Unpacking all of the relevant solution objects is fine, we'll just need > each class to manually list these out. The unpack method can simply be > called in postSolve(). > > On Sat, Feb 15, 2020 at 3:17 PM Christopher Llorracc Carroll < > ***@***.***> wrote: > > > I think we should generalize "unpackcFunc" to something that unpacks ALL > > the created functions ("vFunc, vPFunc" etc); and furthermore, unless it > > imposes serious computational burden, think the funcs should be unpacked > > automatically and without user having to know that they have to do it. > > > > > > > > On Sat, Feb 15, 2020 at 9:11 PM Sebastian Benthall < > > ***@***.***> > > wrote: > > > > > It looks like one reason why this feature remains undocumented is > because > > > there's a workaround method defined for some subclasses, unpackcFunc() > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > < > > > #482?email_source=notifications&email_token=AAKCK73DPTIFGTMENVNNWLDRDBD6BA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132 > > >, > > > or unsubscribe > > > < > > > https://github.com/notifications/unsubscribe-auth/AAKCK77YQECL3MSVAWXYL5DRDBD6BANCNFSM4KOIOCSA > > > > > > . > > > > > > > > > -- > > - Chris Carroll > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > < > #482?email_source=notifications&email_token=ADKRAFJIEXKQCDVL7E5BTPTRDBEWDA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WCNA#issuecomment-586637620 > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/ADKRAFJFL5M5UWWM4GKW6DTRDBEWDANCNFSM4KOIOCSA > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #482?email_source=notifications&email_token=AAKCK75JVYQX3DOGGLCPXDTRDBFATA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WEGQ#issuecomment-586637850 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAKCK74OQ2VHHG3SGIE2HP3RDBFATANCNFSM4KOIOCSA > > . > -- - Chris Carroll — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=ADKRAFNZE5BKEWDIE256QILRDBF33A5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WIOA#issuecomment-586638392>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFOT7CHGOG3LVG4LYWDRDBF33ANCNFSM4KOIOCSA> .

[llorracc]

Why is it so bad ...

Because we have a lot of options, and might have more in the future. You don't HAVE to create vFunc, or other things. So, then, you have to test, for each of them, whether it has been created or not. Seems tidier for a method to have some attribute/tag/whatever-is-the-right-term that indicates whether it is unpackable. That way it is easy to loop over items in dir([object].solution[0]) and unpack those which proclaim themselves to be unpackable. On Sat, Feb 15, 2020 at 9:32 PM Matthew N. White <[email protected]> wrote:

…

There aren't really "tags" in Python, other than giving every single instance of a particular object a dummy attribute. But that would be a waste of memory. Why is it so bad for the model creator to write one line explicitly naming what should be unpacked? Isn't that the most obvious place someone would look to see what's being unpacked-- where it's actually being done-- rather than go back and look through the entire solution code to see which objects get that "tag"? On Sat, Feb 15, 2020 at 3:27 PM Christopher Llorracc Carroll < ***@***.***> wrote: > I guess it would be hard to write something that could just inspect the > object and find and unpack all of the functions defined by it? Seems like > maybe if we tagged each created function with a label like 'unpackable' > that would be better than trying to list the functions that could be > unpacked. > > > > > On Sat, Feb 15, 2020 at 9:20 PM Matthew N. White < ***@***.*** > > > wrote: > > > Unpacking all of the relevant solution objects is fine, we'll just need > > each class to manually list these out. The unpack method can simply be > > called in postSolve(). > > > > On Sat, Feb 15, 2020 at 3:17 PM Christopher Llorracc Carroll < > > ***@***.***> wrote: > > > > > I think we should generalize "unpackcFunc" to something that unpacks > ALL > > > the created functions ("vFunc, vPFunc" etc); and furthermore, unless it > > > imposes serious computational burden, think the funcs should be > unpacked > > > automatically and without user having to know that they have to do it. > > > > > > > > > > > > On Sat, Feb 15, 2020 at 9:11 PM Sebastian Benthall < > > > ***@***.***> > > > wrote: > > > > > > > It looks like one reason why this feature remains undocumented is > > because > > > > there's a workaround method defined for some subclasses, > unpackcFunc() > > > > > > > > — > > > > You are receiving this because you are subscribed to this thread. > > > > Reply to this email directly, view it on GitHub > > > > < > > > > > > #482?email_source=notifications&email_token=AAKCK73DPTIFGTMENVNNWLDRDBD6BA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132 > > > >, > > > > or unsubscribe > > > > < > > > > > > https://github.com/notifications/unsubscribe-auth/AAKCK77YQECL3MSVAWXYL5DRDBD6BANCNFSM4KOIOCSA > > > > > > > > . > > > > > > > > > > > > > -- > > > - Chris Carroll > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > < > > > #482?email_source=notifications&email_token=ADKRAFJIEXKQCDVL7E5BTPTRDBEWDA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WCNA#issuecomment-586637620 > > >, > > > or unsubscribe > > > < > > > https://github.com/notifications/unsubscribe-auth/ADKRAFJFL5M5UWWM4GKW6DTRDBEWDANCNFSM4KOIOCSA > > > > > > . > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > < > #482?email_source=notifications&email_token=AAKCK75JVYQX3DOGGLCPXDTRDBFATA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WEGQ#issuecomment-586637850 > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AAKCK74OQ2VHHG3SGIE2HP3RDBFATANCNFSM4KOIOCSA > > > > . > > > > > -- > - Chris Carroll > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #482?email_source=notifications&email_token=ADKRAFNZE5BKEWDIE256QILRDBF33A5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WIOA#issuecomment-586638392 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADKRAFOT7CHGOG3LVG4LYWDRDBF33ANCNFSM4KOIOCSA > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=AAKCK72YQRFLOPEGMU6CAO3RDBGOVA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WLJQ#issuecomment-586638758>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK752CRQB5MTBKNQAT23RDBGOVANCNFSM4KOIOCSA> .

-- - Chris Carroll

[sbenthall]

For comparison, this is where dolark's DecisionRule, which would generalize over cFunc, etc., is defined:
https://github.com/EconForge/dolark/blob/master/dolark/dolo_improvements.py

In my view, it would make things clearer if those functions that were about control variables, vs. those functions that performed some other role in the solution apparatus (vFunc?) were distinguished during AgentType configuration.

[mnwhite]

Our solution classes are written so that any function that could/should exist is an argument to the init method, and it puts in a dummy NullFunc object if nothing is passed. These objects *always* exist. On Sat, Feb 15, 2020 at 3:40 PM Christopher Llorracc Carroll < [email protected]> wrote:

…

> Why is it so bad ... Because we have a lot of options, and might have more in the future. You don't HAVE to create vFunc, or other things. So, then, you have to test, for each of them, whether it has been created or not. Seems tidier for a method to have some attribute/tag/whatever-is-the-right-term that indicates whether it is unpackable. That way it is easy to loop over items in dir([object].solution[0]) and unpack those which proclaim themselves to be unpackable. On Sat, Feb 15, 2020 at 9:32 PM Matthew N. White ***@***.*** > wrote: > There aren't really "tags" in Python, other than giving every single > instance of a particular object a dummy attribute. But that would be a > waste of memory. > > Why is it so bad for the model creator to write one line explicitly naming > what should be unpacked? Isn't that the most obvious place someone would > look to see what's being unpacked-- where it's actually being done-- rather > than go back and look through the entire solution code to see which objects > get that "tag"? > > On Sat, Feb 15, 2020 at 3:27 PM Christopher Llorracc Carroll < > ***@***.***> wrote: > > > I guess it would be hard to write something that could just inspect the > > object and find and unpack all of the functions defined by it? Seems like > > maybe if we tagged each created function with a label like 'unpackable' > > that would be better than trying to list the functions that could be > > unpacked. > > > > > > > > > > On Sat, Feb 15, 2020 at 9:20 PM Matthew N. White < > ***@***.*** > > > > > wrote: > > > > > Unpacking all of the relevant solution objects is fine, we'll just need > > > each class to manually list these out. The unpack method can simply be > > > called in postSolve(). > > > > > > On Sat, Feb 15, 2020 at 3:17 PM Christopher Llorracc Carroll < > > > ***@***.***> wrote: > > > > > > > I think we should generalize "unpackcFunc" to something that unpacks > > ALL > > > > the created functions ("vFunc, vPFunc" etc); and furthermore, unless > it > > > > imposes serious computational burden, think the funcs should be > > unpacked > > > > automatically and without user having to know that they have to do > it. > > > > > > > > > > > > > > > > On Sat, Feb 15, 2020 at 9:11 PM Sebastian Benthall < > > > > ***@***.***> > > > > wrote: > > > > > > > > > It looks like one reason why this feature remains undocumented is > > > because > > > > > there's a workaround method defined for some subclasses, > > unpackcFunc() > > > > > > > > > > — > > > > > You are receiving this because you are subscribed to this thread. > > > > > Reply to this email directly, view it on GitHub > > > > > < > > > > > > > > > > #482?email_source=notifications&email_token=AAKCK73DPTIFGTMENVNNWLDRDBD6BA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3V6TA#issuecomment-586637132 > > > > >, > > > > > or unsubscribe > > > > > < > > > > > > > > > > https://github.com/notifications/unsubscribe-auth/AAKCK77YQECL3MSVAWXYL5DRDBD6BANCNFSM4KOIOCSA > > > > > > > > > > . > > > > > > > > > > > > > > > > > -- > > > > - Chris Carroll > > > > > > > > — > > > > You are receiving this because you are subscribed to this thread. > > > > Reply to this email directly, view it on GitHub > > > > < > > > > > > #482?email_source=notifications&email_token=ADKRAFJIEXKQCDVL7E5BTPTRDBEWDA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WCNA#issuecomment-586637620 > > > >, > > > > or unsubscribe > > > > < > > > > > > https://github.com/notifications/unsubscribe-auth/ADKRAFJFL5M5UWWM4GKW6DTRDBEWDANCNFSM4KOIOCSA > > > > > > > > . > > > > > > > > > > — > > > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub > > > < > > > #482?email_source=notifications&email_token=AAKCK75JVYQX3DOGGLCPXDTRDBFATA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WEGQ#issuecomment-586637850 > > >, > > > or unsubscribe > > > < > > > https://github.com/notifications/unsubscribe-auth/AAKCK74OQ2VHHG3SGIE2HP3RDBFATANCNFSM4KOIOCSA > > > > > > . > > > > > > > > > -- > > - Chris Carroll > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > < > #482?email_source=notifications&email_token=ADKRAFNZE5BKEWDIE256QILRDBF33A5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WIOA#issuecomment-586638392 > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/ADKRAFOT7CHGOG3LVG4LYWDRDBF33ANCNFSM4KOIOCSA > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #482?email_source=notifications&email_token=AAKCK72YQRFLOPEGMU6CAO3RDBGOVA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WLJQ#issuecomment-586638758 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAKCK752CRQB5MTBKNQAT23RDBGOVANCNFSM4KOIOCSA > > . > -- - Chris Carroll — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=ADKRAFJM7IGUAGCT6QVND5DRDBHNLA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WP7I#issuecomment-586639357>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFP5WVWUPTOT5XP6P7LRDBHNLANCNFSM4KOIOCSA> .

[llorracc]

I don’t see any reason to single out decision rules. There are plenty of purposes (including the *construction* of decision rules) to want direct access to vFunc, vPFunc, and potentially other created objects. Why not have a universal rule (everything that someone MIGHT want to unpack just gets labelled/tagged/identified as such) and then we unpack those things that “want” to be unpacked?

…

On Sat, Feb 15, 2020 at 9:46 PM Sebastian Benthall ***@***.***> wrote: For comparison, this is where dolark's DecisionRule, which would generalize over cFunc, etc., is defined: https://github.com/EconForge/dolark/blob/master/dolark/dolo_improvements.py In my view, it would make things clearer if those functions that were about control variables, vs. those functions that performed some other role in the solution apparatus (vFunc?) were distinguished during AgentType configuration. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=AAKCK7Z5PVUA4IIZRV37K53RDBIAXA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WS7I#issuecomment-586639741>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK76SH7XCHMSNAXONDPDRDBIAXANCNFSM4KOIOCSA> .

-- - Chris Carroll

[mnwhite]

We can just have it unpack everything in solution[0]. I'd just prefer a more controlled method. On Sat, Feb 15, 2020 at 3:57 PM Christopher Llorracc Carroll < [email protected]> wrote:

…

I don’t see any reason to single out decision rules. There are plenty of purposes (including the *construction* of decision rules) to want direct access to vFunc, vPFunc, and potentially other created objects. Why not have a universal rule (everything that someone MIGHT want to unpack just gets labelled/tagged/identified as such) and then we unpack those things that “want” to be unpacked? On Sat, Feb 15, 2020 at 9:46 PM Sebastian Benthall < ***@***.***> wrote: > For comparison, this is where dolark's DecisionRule, which would > generalize over cFunc, etc., is defined: > https://github.com/EconForge/dolark/blob/master/dolark/dolo_improvements.py > > In my view, it would make things clearer if those functions that were > about control variables, vs. those functions that performed some other role > in the solution apparatus (vFunc?) were distinguished during AgentType > configuration. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #482?email_source=notifications&email_token=AAKCK7Z5PVUA4IIZRV37K53RDBIAXA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WS7I#issuecomment-586639741 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAKCK76SH7XCHMSNAXONDPDRDBIAXANCNFSM4KOIOCSA > > . > -- - Chris Carroll — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#482?email_source=notifications&email_token=ADKRAFPI3ZUU3RHDLMVUGQ3RDBJLRA5CNFSM4KOIOCSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WZPA#issuecomment-586640572>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFJ3OCZBIFE6XZAVOG3RDBJLRANCNFSM4KOIOCSA> .

[sbenthall]

I wonder if this issue can be revisited in light of what we are discussing in #798

I wonder what, in an ideal future where we've done some refactoring, the "solution" might look like.

My impression is that it:

• Should look like a decision rule, in that it provides a rule for each control variable, conditional on the state and shock inputs available at that point of control
• May also include other calculated properties of interest.