Does the IndicatorBase class "automatically" fill all TimeSeries.Values with Double.NaN initially, or does one's indicator definition code need to do that explicitly for all undefined leading indicator values? The docs aren't clear on this, although the docs do clearly indicate a "new TimeSeries(DateTimes)" definition with one parameter will automatically fill in with Double.NaN. (However, IndicatorBase inherits from a zero parameter TimeSeries, and that behavior is undocumented.)
Does this Double.NaN front-end padding take the place of FirstValidValue for a WL6 indicator definition? The docs for the read-only FirstValidIndex property (both WL7 TimeSeries and Indicators) seem to suggest it may.
Does this Double.NaN front-end padding take the place of FirstValidValue for a WL6 indicator definition? The docs for the read-only FirstValidIndex property (both WL7 TimeSeries and Indicators) seem to suggest it may.
Rename
The usual pattern in an indicator Populate method is to make an assignment like this:
DateTimes = source.DateTimes;
The “source” is either the BarHistory or TineSeries that’s the first parameter of the indicator. Making this assignment synchronizes the DateTimes of your indicator and fills the values with Double.NaN.
DateTimes = source.DateTimes;
The “source” is either the BarHistory or TineSeries that’s the first parameter of the indicator. Making this assignment synchronizes the DateTimes of your indicator and fills the values with Double.NaN.
Thanks. So one needs to first assign the DateTimes as shown in Reply# 1 to initialize all Values to Double.NaN. Any other Value assignments need to follow this DateTimes assignment. Thanks for the clarification.
In WL6, the indicator base class did this type of initialization (with base parameters). In WL7, Populate() is doing this instead. I think WL6's approach is easier to follow.
In WL6, the indicator base class did this type of initialization (with base parameters). In WL7, Populate() is doing this instead. I think WL6's approach is easier to follow.
Probably true. At this stage it’s just something that indicator creators will need to learn and adapt too.
Filling a TimeSeries with zeroes on initialization sometimes helps avoid issues:
CODE:
TimeSeries result = new TimeSeries(DateTimes, 0);
I wish the TimeSeries.FirstValidIndex property had "protected" set status, so the constructor of a derived class could set it if necessary. Right now it's read-only. I'm assuming it can only be set by the TimeSeries constructor (although I don't know what criteria that constructor uses), and by the Populate() constructor of the IndicatorBase.
It’s implemented by returning the index of the first non-NaN value.
So if you are combining (e.g. adding) two TimeSeries together, one would want to use the shortest time series to "new TimeSeries(shortestSeries.DateTimes)" to contain the arithmetic result.
Of course, one would want to employ TimeSeries arithmetic operators so this is handled transparently, but Math.Net will return a double[] result, and that needs to be copied into an empty TimeSeries created with the "new" TimeSeries operator. And I want that "new" operator to set FirstValidValue appropriately for the incoming double[] array.
Maybe the TimeSeries type could use a new constructor?
This isn't a problem with an indicator (created via a Math.Net double[]), because an indicator has the Populate() constructor for handling this.
Of course, one would want to employ TimeSeries arithmetic operators so this is handled transparently, but Math.Net will return a double[] result, and that needs to be copied into an empty TimeSeries created with the "new" TimeSeries operator. And I want that "new" operator to set FirstValidValue appropriately for the incoming double[] array.
Maybe the TimeSeries type could use a new constructor?
CODE:
TimeSeries newResultToPlot = new TimeSeries(referenceSeries.DateTimes, double[] computedVector);
This isn't a problem with an indicator (created via a Math.Net double[]), because an indicator has the Populate() constructor for handling this.
I see no reason why we can’t add a setter to that property, to override the default behavior.
The website won't let me thumbs up Reply# 8.
Thanks, I passed this on to our web developer!
QUOTE:
The website won't let me thumbs up Reply# 8.
Fixed. Thank you!
Your Response
Post
Edit Post
Login is required