Skip to content

Variables vs Functions

Free variables vs function evaluation inside a stage

Think of a stage as a collection of transformations between perches (arrival → decision → continuation), i.e. maps on state spaces (and information sets). For example, the arrival→decision transition is a map of the form

\[ g_{ad}: X_{arvl}\times\mathcal{F}\to X_{dcsn}. \]

Key observation

The forward equations (state transitions, information timing) are already enough to define what the backward iteration must mean. E.g. a Bellman recursion written in “time-indexed variable” notation,

\[ V_t - u(c_t) = \beta\,\mathbb{E}[V_{t+1}], \]

is always interpretable as a statement about function evaluations at the relevant state(s).

Discipline (revised proposal)

We can allow free variables, but we need a hard semantic distinction between:

  • Perch-indexed tokens (e.g. f (unmarked), V[<], c[>]), which are never "free scalars"; and
  • Unindexed tokens, which may be free (parameters/settings, locally defined auxiliaries, or variables bound by operators).

The guiding rule is:

\[ f[\_p]\ \equiv\ f_p(x[\_p]), \]

where \(x[\_p]\in X_p\) is the perch-\(p\) state and \(f_p: X_p\to\mathbb{R}^k\) is the corresponding field. This is just function evaluation with an implicit argument, not a new arithmetic operation.

Namespaces (rough but useful)

  • Period-global namespace: the state coordinate names (e.g. a, w, H, y) are global within the period. For each perch \(p\), a coordinate name induces a projection/coordinate map \(a_p: X_p\to\mathbb{R}\). So saying "a is the decision state" is acceptable as shorthand; formally, a (unmarked, at decision) is the \(a\)-coordinate of \(x[\_dcsn]\).
  • Stage-local namespace: value functions and other fields solved/defined within a stage (e.g. V, dV, policy functions, auxiliaries) are local unless explicitly linked across stages.
  • Operator-bound variables: variables introduced by operators (the \(c\) in \(\max_c\), the \(y\) in \(E_y\)) are bound in the usual way.

Notation / “syntactic sugar”

When we write a stage-level symbol with a perch tag (or unmarked at the decision perch), we should read it as evaluation at that perch's state. For example,

\[ a\ \text{(unmarked) is sugar for}\ a_{dcsn}(x_{dcsn}), \]

where \(x_{dcsn}\in X_{dcsn}\) is the decision state and \(a_{dcsn}\) is (typically) a coordinate projection / derived state component.

Formal (non-sugar) layer: Mathematica-style function definitions

At the formal layer, it can be helpful to write the fields as explicit functions using Mathematica-style notation. For example,

\[ f[\_x] := x^2 \]

is read as “\(f\) is a function; for an input \(x\), \(f(x)=x^2\).” In our setting, the relevant argument is the perch state \(x[\_p]\in X_p\), so we can write (schematically)

\[ V_p[\_x_p] := \cdots,\qquad c_p[\_x_p] := \cdots,\qquad a_p[\_x_p] := \pi_a(x_p). \]

Then the perch-tag sugar is simply

\[ f[\_p]\ \rightsquigarrow\ f_p[x[\_p]]. \]

Example (the earlier “ambiguous” arithmetic becomes transparently well-typed):

\[ w[>] = a[>] + c[>] \]

means, at the formal layer,

\[ w_{cntn}[\_x_{cntn}] := a_{cntn}[\_x_{cntn}] + c_{cntn}[\_x_{cntn}]. \]

No new arithmetic is introduced; we are just working with ordinary function evaluation/composition and suppressing explicit arguments in the surface syntax.

This resolves apparent ambiguities like

\[ w[>] = a[>] + c[>], \]

because all terms are functions of the same argument \(x_{\succ}\): we are adding a state coordinate to a policy evaluated at that state, yielding another function of that state.

Why not treat \(V\) (decision-perch value) as a free variable?

If \(V\) (at the decision perch) were a free variable, then—prior to choosing a grid/simulation—its meaning (and thus its mathematical properties) would be underdetermined. In contrast, reading

\[ V\ \equiv\ V_{dcsn}(x_{dcsn}) \]

makes the semantics explicit: \(V_{dcsn}\) is the (unknown) value function object, and the algorithm's job is to approximate that object; discretization is an implementation detail.

So: perch-indexed symbols are not free variables; they are evaluations of fields at a perch state. Free variables can exist, but they must be unindexed and properly scoped (parameters/settings, operator-bound variables, or local definitions).