Yes, the behavior of the function is dependent on the method and block it is called from. For example, within the age_index block of a model (created for you from a model), it can access future horizons as it initializing some values prior to running the main evaluation block. However, in the main block of the UDL (evaluation method), it does not have access to future data. If there is data you want to access there such as a current forecast of interest rates (not the current scenario risk factor), you could pass it in as a PMX.
Here is more detail around what I added last time:
When you use the function get_rf_by_horizon there are a few rules that can help ensure that it is being used correctly. The function should be used only in an INST_INIT or MAIN block in user-defined logic or in a model variable expression. The rules of what is acceptable depends on which one of those places it is found. However, you should normally expect the offset to be negative.
From Model Variable Expression
When the function is inside a model’s variable expression, and that variable is of type static or age-indexed, it is being called from the snapshot date. This is important to know because of the second argument, the offset. Given that it is in a model’s variable expression, if that variable is an age-indexed variable, then the variable expression should use the variable _horizon_ in it. Otherwise, it is either incorrect or in the wrong place.
From INST_INIT
When the function is in INST_INIT, the second argument should be non-positive. This is because it is being called from time period 0 and there is not yet a scenario. Hence, the only valid offsets are less than or equal to zero.
From MAIN
Finally, when the function is in the MAIN block, the offset must be strictly negative. Even though there is now a scenario, the offset is relative to the current horizon. SAS Model Implementation Platform truncates all economic data that occurs after the maximum number of horizons that will be run. Any positive number is guaranteed to have a problem because get_rf_by_horizon will eventually try to access economic data that is not available. Additionally, there is no reason to use an offset of 0 since you can access that risk factor directly without using the function. In fact, there is considerable benefit to not using the function with an offset of 0. The function itself is computationally expensive, so avoiding it is better.
In terms of the blocks and methods running, here is an example of what happens on one thread for a stochastic evaluation (price) method, assuming no scoring and no mitigation:
START OF PER-THREAD BEHAVIOR:
INIT blocks for all model methods
INIT blocks for all price methods
------------- value Portfolio --------------------------------------
loop ( positions in specified portfolio ) {
INST_INIT block of price method -------------------------------
STATIC_INIT blocks of associated model methods |
MAIN block of pricing method for basecase |
... and MAIN blocks of associated model methods |
loop over scenarios { |
AGE_INDEX block of associated model methods | evaluate
loop over specified MCSIMULATIONS { | loan
loop over time horizons { |
MAIN block of price method |
... and MAIN blocks of associated model methods |
} |
} |
} -------------------------------------------------------------
}
TERM blocks for all price methods
TERM blocks for all model methods
END OF PER-THREAD BEHAVIOR
