|
<< Click to Display Table of Contents >> Timeseries lags |
![]() ![]()
|
In general, when handling a timeseries lag like prt x[-1];, it would be a waste of time to create a temporary light timeseries (more on light timeseries here), where the observations/data in the data array are basically just moved one position to reflect the lag.
Imagine that you have a data array running from a[0] to a[199], where each element represents a timeseries observation. Now imagine that the a[100] element corresponds to the date 2000q1, a[101] to 2000q2, etc. So there is in a sense a pointer from the date 2000q1 to the index 100 (more about these pointers here). Now, when dealing with a lag like x[-1], we could of course take the whole data array a[0]-a[199] and move each element one position to the right. Following this, the "new" value of a[101] would correspond to the "old" value of a[100], and hence, the date 2000q2 would point to the value that used to be stored in a[100], that is, the previous 2000q1 value.
Constructing a new series object and moving 199 values of the a array like this would be a tremendous waste of effort, because it is much easier to just adjust the pointer. Basically, the O.Indexer() method gets called with the series x and the lag -1 as arguments.
Inside O.Indexer(), it is first checked whether the index is a lag or lead. If the index starts with the character -, it is a lag, with + it is a lead, and else it is treated as indexing a particular date (like x[2000q1]). In our case, the index value is recognized as a lag (EIndexerType.IndexerLag), and next the following takes place:
// x[-1] |
So a new timeseries temp is created, of the same type and frequency as the "incoming" timeseries. The data object containing among other things the timeseries observations is set equal to the original data object. And then the field .dataOffsetLag is set to -1. This field basically adjusts the index when "translating" from a date like 2000q2 to a particular index. If the date 2000q2 normally points to a[101] of the data array, the .dataOffsetLag will point this to a[101-1] = a[100] instead. So in all code that deals with these timeseries data arrays, the dataOffsetLag is used.
Note that the data sub-object of the new temp timeseries just points to the same original data object. But in any case, an expression like x[-1] is intermediate, and the data part of the temp timeseries will not be changed (but only read). This approach eliminates copying of the data object, which would be a waste of time. In a sense, this temp object is comparable to using light timeseries for intermediate expressions, cf. here. Neither this temp object or a light timeseries is intended for long-term storage in a databank, but instead just stores an intermediate expression.
The offset is reflected in for instance this C# method:
public int GetAnchorPeriodPositionInArray() |
So whenever we are obtaining the anchor position (cf. the explanation here) in order to look up data in a timeseries, the anchor is offset by .dataOffsetLag if there is a lag present.
The performance advantages of doing this compared to copying an offsetting a whole data array are probably quite large in cases where lags are used extensively.