Question to users: keep or cut initialization period values?

[DaveSkender]

In a recent issue (#173) a user correctly identified that an indicator had less precision in an initialization phase for an indicator. Some indicators, like ADX, EMA, or others that use smoothing techniques require a runway of about 150-250 periods before the algorithm produces precision to 2 or more decimal places. Early initialization values can be imprecise to small 0.x to 0.0x decimals. This is not unusual for some indicators and precision to 0.00x is not always required for most use cases, especially when the user understands what is happening and can design around it by not using the first 150-250 values. Indicators that require a runway have this mentioned in the documentation.

Question: would you prefer that the library exclude values that don't meet a certain higher precision threshold or keep them? Excluding them would force users to use more history (and I'd probably update the Exception rules to enforce).

Thumbs up = enforce greater precision / exclude initialization values / require more history in Exception rules
Thumbs down = allow 0.x and 0.0x decimal imprecision in early periods and let me decide what to do

Feedback appreciated. Comment below with other ideas.

[DaveSkender]

As a side note, charting providers will typically calculate indicators on the backend with significantly more history than what they show on the actual chart. They basically truncate the initialization period, so you'd not see these initialization values in those applications. My assumption would be that you, the user, would basically do the same thing, compute indicators with this in mind then only use the post-initialization data. See How much historical quote data do I need?.

[DaveSkender]

I'm going to opt for allowing small imprecision in the initialization periods for now.

Please see #306 for a continuation on this topic, where you can voice your preferences.