SMA-and-FastSMA-Plots-are-identical

Interesting, they are functionally equivalent, even according to their description, so it's as designed. But if the FastSMA really is just faster, I don't know why it was introduced as a separate indicator instead of simply replacing the SMA's internal logic with the superior algorithm. We'll have to look at the possible side effects of doing so.

QUOTE:
... if the FastSMA really is just faster, I don't know why it was introduced as a separate indicator instead of simply replacing the SMA ...

Exactly. What does one gain by using the slower version? I wondered that back with WL6. There's no need to have two.

It's misleading for a moving average to start plotting values even before it has acquired the full data required for the calculation, as FastSMA does; in fact, it starts plotting from bar 0.
Hope it wasn't being used for any calculations inside the program as that may have produced erroneous results (for the bars preceding the period specified).

QUOTE:
It's misleading for a moving average to start plotting values even before it has acquired the full data required

Then the FastSMA indicator isn't setting the FirstValidIndex property correctly, and that should be corrected so it's not plotting erroneous stuff.

Moreover, the FirstValidIndex property needs to be included in the IndicatorBase documentation. Somehow that got left off.

It’s documented in TimeSeries, since that’s where it’s defined. IndicatorBase inherits it.

I understand your point, but even examples like for the SMA fail to discuss or set the FirstValidIndex property. It needs to be included in the indicator examples.

We can work on fixing that. Anyway, there's really no doubt when the first index is valid since all the values prior to it return "NaN".

The example does not need to set it. It’s determined dynamically based on the first bar of data that isn’t NaN.

Cool, glad I didn't spend more time on that!

QUOTE:
The example does not need to set it. It’s determined dynamically based on the first bar of data that isn’t NaN.

I use FirstValueIndex to set the StartIndex, and the dynamic setting is not setting FirstValueIndex. If the dynamic behavior is suppose to be setting FirstValueIndex, it's not working right.

This wasn't a problem with WL6, but it is a problem with WL8 indicators.

If you mean FirstValidIndex, my experience is just the opposite. What's the example?

There are indicators (perhaps FastSMA maybe one) that never gets their FirstValidIndex set. In addition, until Populate() is called, there's no way to determine what the FirstValidIndex actually is. And Populate() is called after the IndicatorBase constructor is called, so where is the dynamic code base located that automatically sets FirstValidIndex? It can't be in the IndicatorBase constructor.

All my indicators explicitly set FirstValidIndex in Populate(); otherwise, it doesn't get set.

The need for the Populate() method complicates building the indicator, but if you eliminate Populate, then how are you suppose to develop indicators without the need to write WPF code and still have drag-and-drop events work? Perhaps you could use Windows.Forms for that part like WL6 does. (I'm trying to decide if that's a good thing or a bad thing?)

In order to clear up any misinformation, there is no problem with FirstValidIndex in WL8's indicators.

FirstValidIndex works by looking at the data, so of course it needs to be populated before it can return an expected value.

I don't understand why you feel you need to set FirstValidIndex in your Populate method. Just leave it to use its default behavior.

To answer your other question, the logic is within the FirstValidIndex "getter" method implementation.

QUOTE:
the logic is within the FirstValidIndex "getter" method implementation.

Well, that should work. So the question remains, "Why can't I pull FirstValidIndex values in strategy code to set the StartIndex?

Let me research that and then start a new topic to address these issues.

I'm also wondering why the original poster, in Reply# 3, is saying FastSMA is plotting invalid initial values. Is its FirstValidIndex get code broken?

No, the implementation of the FastSMA does assign a value even at bar zero, therefore FirstValidIndex correctly returns zero.

QUOTE:
therefore FirstValidIndex correctly returns zero.

Well, if you're doing an SMA (or FastSMA) of period 10, then the FirstValidIndex would be 9, not zero. Sounds like you confirmed a problem. So Reply# 3 is reporting the problem correctly. (I haven't checked FastSMA myself.)

In this example, I would want my StartIndex = 9 (or larger), but not 0.

The sample code given for the SMA for WL6 is:

CODE:
FirstValidValue = period - 1 + ds.FirstValidValue;

and that doesn't compute to zero. Could we be talking about two different things?

Again, to eliminate any disinformation, there is no problem with the FirstValidIndex property.

QUOTE:
No, the implementation of the FastSMA does assign a value even at bar zero...

FastSMA in WL6 plots from correct bar:


FastSMA in WL8 plots from bar 0:



It's only in WL8 that FastSMA plots from bar 0. And it's wrong for an indicator to start plotting before it has had the required data.
The implementation in WL8 is incorrect. Moreover, I don't really see the purpose of this indicator.

1. The implementation in WL8 is correct (word for word).
2. In WL6 it plots the way it because it's artificially instructed to:

CODE:
base.FirstValidValue = period - 1 + ds.FirstValidValue;

3. If you don't see the purpose, let me tell you: a 30% performance boost.

Thanks for clarifying Eugene. You see, Sammy WL8 is actually more correct than WL6 in this case. You can safely just ignore FastSMA if you like.

Just noticed: DEMA (Double Exponential Moving Average), under Advanced Smoothers, also plots from bar 0 in WL8 but plots from the proper bar in WL6.

I don't know how widespread this issue is.

It's probably a fairly widespread fault in WL6, which relied on forcing indicators to explicitly set a property instead of determining the first bar with data dynamically like WL8 does.

I prefer the way WL6 does it when it comes to setting the StartIndex. I wouldn't want to start my trading until the indicators correctly stabilized. Your risk tolerance may be different.

I can see that point of view, and I think there's more to gain by assigning it directly in cases where it makes sense. Fortunately the FirstValidIndex supports an assignment to override the default behavior. I'll go ahead and assign the value for FastSMA and DEMA, and will check the other indicators too.

QUOTE:
I think there's more to gain by assigning it directly in cases where it makes sense.

Exactly. I remember when WL7 was first released, I requested unprotecting the FirstValidIndex property so my indicators--which use a statistical analysis that's data dependent--can assign FirstValidIndex explicitly.

The problem is the statistical analysis is data dependent, so the FirstValidIndex (and subsequently the StartIndex) will vary from one stock to the next. And StartIndex needs to adapt to that variation. So this is more about dynamically assigning StartIndex and beginning trading when it makes sense to do so. (The FirstValidIndex business is just coming along for the ride.)

The good news is that most indicators aren't doing a statistical analysis, so their FirstValidIndex value isn't as problematic.