|
<< Click to Display Table of Contents >> Assignments |
![]() ![]()
|
Assignment statements can be for instance #m[1, 2] = pch(x[-1] + 1)[2020], where the RHS (right-hand side) is assigned to the LHS (left-hand side). In this case, a matrix cell (row 1, column 2) is assigned with a scalar value.
Statements always include the = symbol (sometimes adjusted, like += and similar). When an assignment is performed, the RHS side is calculated first. The RHS in a statement is always an expression, so what happens when the RHS is to be assigned to the LHS? In the ANTLR parser, assignments are issued with an ASTASSIGNMENT node, and this kind of node has been explained briefly in the section on AST tree walking. We can continue the example from the previous section (looking at pch(x1+x2)) and try out a similar assignment: y = pch(x1+x2). After parsing, AST tree walking and C# code emitting, this will be translated into the following:
//y = pch(x1+x2) |
There are two O.AdjustT0() calls, first deducing 2 from smpl.t0, and later on adding 2 again. Even though the so-called "lag problem" is solved via the O.Smpl() method calls (cf. the section on expressions), deducting and adding 2 from smpl.t0 is more of a safety-first approach, so that we calculate over a few more observations in the beginning of the sample, to avoid missing values in the result.
Else, the RHS of the ivTmpvar21 variable corresponds to what we saw in the expressions section. Nothing new here, the interesting thing here is the last C# line, calling O.Lookup(). In general, the O.Lookup() methods either tries to locate a Gekko variable (normally in a databank), or tries to assign something to a Gekko variable. The latter is the case here. O.Lookup() has the following definition:
public static IVariable Lookup(GekkoSmpl smpl, Map map, string dbName, string varname, string freq, IVariable rhsExpression, LookupSettings isLeftSideVariable, EVariableType type, O.Assignment options) {...} |
So Lookup() is basically called with this:
•A normal smpl (sample time period)
•No map is called: we are not finding the variable inside a map
•No dbName (databank name) is given: that is, we have not written for instance b1:y = pch(x1+x2);, designating a b1 databank.
•varname = "y"
•freq is not given explicitly, like in for instance y!a = pch(x1+x2);.
•rhsExpression is set to ivTmpvar21, which is the RHS of the assignment.
•isLeftSideVariable is set to LookupSettings(O.ELookupType.LeftHandSide), which basically just means that it is a LHS assignment.
•type is set to EVariableType.Var, which just means that no LHS type has been stated. For instance, one could write series y = pch(x1+x2) to make sure that the LHS variable becomes a timeseries. This is not necessary here, but in some cases the type can be stated, like for instance date %d = 2020; (where %d becomes a Gekko date), because if just using %d = 2020, the variable %d will become a value. In essence, date %d = 2020; performs a type conversion, similar to using %d = date(2020);.
•options is just a raw O.Assignment object, which basically just means that there are no special options. But this object can store all sorts of assignment options, for instance .opt_d for time-difference, .opt_p for percentage growth, info on label, source, units, etc.
Dynamics
There is some special code to handle dynamic lag statements like x = x[-1] + 1;.
Gekko emits both a check, and the "real" assignment. These look like the following in C#:
Action assign_40 = () => { |
The first part, assign_40 is just normal assignment code, like the assignment in the first code box in this section. The second part, check_40, only calculates the right-hand side, corresponding to ivTmpvar21.
So O.RunAssigmentMaybeDynamic() runs check_40 first, and if the right-hand side is a timeseries variable, and if the left-hand side appears with a lag on the right-hand side, check_40 will return with the value true, and the assignment will be run period by period in an outer loop (so that the lags can accumulate). To allow this, the user must have decorated the assignment with a <dyn> tag.