Introduction to RASON
About RASON Models and the RASON Server
Rason Subscriptions
Rason Web IDE
Creating and Running a Decision Flow
Defining Your Optimization Model
Defining Your Simulation Model
Performing Sensitivity Analysis
Defining Your Stochastic Optimization Model
Defining Your Data Science Model
Defining Custom Types
Defining Custom Functions
Defining Your Decision Table
Defining Contexts
Using the REST API
REST API Quick Call Endpoints
REST API Endpoints
Decision Flow REST API Endpoints
OData Endpoints
OData Service for Decision Flows
Creating Your Own Application
Using Arrays, For, Loops and Tables
Organization Accounts

Indexed array formulas

The goal of indexed array formulas is to allow more flexible definitions and evaluations. In the RASON modeling language, the for() definition is not treated as a loop (as in a typical programming language); rather, for() will be treated as a declarative statement to exclusively assign attributes to indexed array formulas. The biggest advantage of this array formula type is that it allows the reverse mode of evaluation. Let's discuss the basics of the indexed array formulas on the next example:

"for(p in 'part')" : {
  "constraint[p]":{ formula:"sumproduct(parts[p, ], x) - inventory[p]", upper:0}
}

The result of this evaluation is a 1-D horizontal/vertical array, 2-D array, or m-D table.

The indexed array formula does not behave in the same way as the parallel array formula. The parallel formula is interpreted only once, and hence, provides values for all result components simultaneously. The indexed array formula is executed only for a preset combination of the participating indices. In the example above, there is only one index in the formula, but in general the number of indices is usually > 1.

As mentioned above, the line of code "for (p in 'part')" in the RASON modeling language does not behave in the same way as a "for" statement in a typical programming language. Rather, for() in RASON simply describes the indices and their index sets as attributes to the array formula but it does not determine the current value of the indices. (Recall that in the RASON modeling language for() is not an iterator.) Though "for()" assumes the possible evaluation of the formula for all index combinations, the nature of the model may request only a few or even one combination/setting of indices to evaluate. Evaluation of the model is not sequential, but rather, tracks the dependencies of the function beginning with the top formula then tracking down to the variables. The key in an indexed array formula evaluation is that the dependency is tracked not only by the nodes with formulas, but also by the desired combination of indices attached to that node.

Our example above is very simple; the indexed array formula is independent from any other formulas. Since this indexed array contains an upper bound, we can assume these three lines of code appear in the constraints section. We have defined multiple constraints here; one constraint for each p in 'part'. A "for()" definition may also appear in the formulas: section. In the above example, if we want to evaluate the constraint related to the "tube" element within the "part" index set, we set p = "tube" and execute the formula only for that particular index. The additional components in the array formula will be ignored.

Introducing indices in array formulas allows for more advanced evaluation algorithms. The following example demonstrates dependency of a given array component on its previous component.

formulas: {
 "for(t in 2..time)": {
"coordX[t]": { dimensions: ['time'], value: 1.570796, formula: "coordX[t-1] + change[t]" }
   }
}
constraints: {
   cx: { formula: "abs(coordX[time] - TargetX)", upper: 10 }
}

In this example code, the cx constraint will be evaluated first. This constraint depends exclusively on the last component of {coordX[10]}. (In this example, time = 10.) As a result, RASON starts tracking the dependencies starting with {coordX[10]}. However during that evaluation we find another dependency on {coordX[9]}. Likewise when evaluating {coordX[9]}, we find a dependency on {coordX[8]}. This dependency tracking continues until {coordX[1]} is reached. Once {coordX[1]} is evaluated, we can evaluate {coordX[2]}, which allows us to evaluate {coordX[3]} and so on until we reach {coordX[10]} which ultimately results in the computation of the constraint cx.

Back to Non-Parallel Array Formulas