Object for representation constraints on control variables / domain /optimization bounds

[sbenthall]

Often a control variable has a limited domain.

For example, c <= m, or consumption must be less than current market resources.

This constraint is in effect a bound on the optimization problem as they agent chooses how much to consume.

Rather than have this constraint be hard-coded into each model's solution code, it would be better if information about this bounds were part of model configuration.

The scipy library has a dedicated Bounds object for precisely this purpose. (It also has Constraint objects; I'm not sure how these are used differently.)

https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.Bounds.html https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.LinearConstraint.html?highlight=constraint#scipy.optimize.LinearConstraint

A difference between scipy's Bound object and what we would need is that Bound uses arrays of floats, whereas the information we need is a relation between model variables that would be instantiated as something like a Bound when the optimization is performed.

I believe this functionality is called the Domain in the Dolo syntax:

https://github.com/EconForge/dolo.py/blob/bde421efe00ecc7cb78b2cead1594b0729aa3a7c/doc/source/modeling_language.rst#domain-section

Maybe there is some part of Dolo that we could use for this feature.

[mnwhite]

The borrowing constraint is part of the model configuration, in the sense that it's a parameter in the agent's problem: BoroCnstArt is the "artificial borrowing constraint" \underbar{a} <= a_t below which the agent is not allowed to end the period. That translates into a constraint on the control variable: a_t = m_t - c_t --> underbar{a} <= m_t - c_t --> c_t <= m_t - underbar{a}.

In the long run, big picture, "magic solver", representing constraints on the control space as a function of the state space is something we want. But generically handling constraints that bind in only part of the state space is hard, and I'd argue that changing the nature of a constraint (rather than shifting some parametric aspect of it) is actually changing the model itself.

On Thu, Sep 23, 2021 at 1:21 PM Sebastian Benthall @.***> wrote:

Often a control variable has a limited domain.

For example, c <= m, or consumption must be less than current market resources.

This constraint is in effect a bound on the optimization problem as they agent chooses how much to consume.

Rather than have this constraint be hard-coded into each model's solution code, it would be better if information about this bounds were part of model configuration.

The scipy library has a dedicated Bounds object for precisely this purpose. (It also has Constraint objects; I'm not sure how these are used differently.)

https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.Bounds.html

https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.LinearConstraint.html?highlight=constraint#scipy.optimize.LinearConstraint

A difference between scipy's Bound object and what we would need is that Bound uses arrays of floats, whereas the information we need is a relation between model variables that would be instantiated as something like a Bound when the optimization is performed.

I believe this functionality is called the Domain in the Dolo syntax:

https://github.com/EconForge/dolo.py/blob/bde421efe00ecc7cb78b2cead1594b0729aa3a7c/doc/source/modeling_language.rst#domain-section

Maybe there is some part of Dolo that we could use for this feature.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/issues/1066, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKRAFJYGVIRJQSJ5UUZBBLUDNOYJANCNFSM5EUFPFAA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[sbenthall]

I'm working towards building a magic solver.

A magic solver requires a more modular, general way of defining models.

That's what the FrameAgentType is: https://github.com/econ-ark/HARK/blob/master/HARK/core.py#L891

Certainly that FrameAgent will use a specialized object to represent these constraints.

I think that ideally, the other models in HARK would be adapted to use these new data structures for defining models as they become available.

By analogy -- it was good to capture the logic of probability distributions into objects and use them, rather than have ad hoc distribution code in each model class.

[sbenthall]

There are Constraints objects in DCP:

https://www.cvxpy.org/api_reference/cvxpy.constraints.html?highlight=constraints

[alanlujan91]

On "magic" solvers:

https://docs.scipy.org/doc/scipy/reference/tutorial/optimize.html https://docs.scipy.org/doc/scipy/reference/optimize.html

with particular focus on minimize_scalar and root_scalar for simple problems and minimize and root for more complex problems.

[llorracc]

@sbenthall,

The set of problems that we have defined as the domain for HARK is Bellman problems. Explicitly, this includes non-convex problems -- like, for example, the DCEGM problem.

I am enthusiastic about the suggestion that we should study the set of alternative ways of encoding the problems we are interested in solving. For example, making the various elements of the problem (like constraints) "objects" might be useful.

Effectively, what Dolo does is to take the traditional equation-based way of writing problems and convert the set of equations into a set of software objects. I'm open to the idea that directly defining the objects might be a reasonable alternative approach, perhaps with greater flexibility.

There is one known way of solving any problem in our class: Value function iteration. By some definition of a "magic" approach, VFI is it. But VFI is excruciatingly slow and subject to the most extreme imaginable forms of the curse of dimensionality.

The specialized techniques that are orders of magnitude faster (that we are using) make it possible actually to solve problems that would be hopeless using generic VFI.

So, I'm all in favor of surveying the tools that are out there for representing and solving various classes of problems, to make sure we have a good sense of the alternative ways in which problems are specified. In the end I'll be surprised if there is a better way of doing it than by sets of equations -- per Dolo.

My sense is that alternatives to equation-based descriptions exist precisely in order to impose restrictions (like convexity) on the problem -- that is, to prevent the user from writing down general purpose problems.