Indicator source taxonomy

[mihakralj]

I peeked into a source tree after a long absence, pondering to contribute some code. But I am a bit puzzled with structure for each indicator. There are 4-6 source files per indicator, and it would be helpful to understand what files (and methods) a typical indicator should include, which are required and which are optional.

• *.Analysis.cs
• *.API.cs
• *.Models.cs
• *.Series.cs
• *.Stream.cs
• *.Utilities.cs

My current deduction (correct me if I am wrong):

• the old-style indicators (that require a full sequence of Quotes to run) are methods with array of quotes - in partial class implementation in *.Series.cs.
• the new-style indicators (that can work on additive data and don't need recalc each time new quote is added) are classes with .Add() method - implemented in *.Stream.cs.

For new-style indicators you refactored *.Series.cs so instead of using "traditional" algo, it uses the Class.Add() to iterate through all values in the array of quotes.

[DaveSkender]

Warning

The convention depicted below for v3 is obsolete

EMA in the v3 base branch is probably a better example of where I’m headed for the new file taxonomy. It’s still evolving.

[indicator].Api.cs - the primary public facing interfaces.
[indicator].Common.cs - static methods common to both time series and streaming (e.g. param validation, increment)
[indicator].Models.cs - static data class structures (e.g. EmaResult class and properties)
[indicator].Stream.cs - manages streaming internals and data in memory
[indicator].Series.cs - classic full time-series methods (refactored to use Increment(..))
[indicator].Utilities.cs - custom extension methods
info.xml - inline VS IDE XML documentation, for public APIs

The next step in my game plan for v3 was to just refactor out the static increment and related series call for all of them, without trying to add all of the full observer streaming in one massive change. That’d at least allow some people to instrument their own custom streaming models — not everyone will want to use our managed data cache.

[DaveSkender]

Yes, that’s correct if you’re feeding trades data or higher frequency candles than what you want coming out. You’d need to aggregate it yourself currently — too many feed scenarios to try to put that kind of logic in now, but might be a good auto-aggregator overload option to add later.

[mihakralj]

welcome to my club, I am keeping a seat for you right over here! :-)

All my 'iterators' (all of my Add methods are equivalent to your iterators) derive from a base class with boolean parameter update - that signals a decision if input is a fresh candle or an update of existing one. That boolean parameter is then set by an aggregator - or any other external logic.
And it works with events too, as the update parameter is passed from class to class:

	public virtual (DateTime t, double v) Add((DateTime t, double v) TValue, bool update = false) {
		if (update) {
			this[this.Count-1] = TValue;
		}
		else {
			base.Add(TValue);
		}

		OnEvent(update);
		return TValue;
	}

[DaveSkender]

That overload would be a good prototype to add to EMA if you’re interested. Sounds like a useful thing to open up different feed choices. I think a simple pre-processor Add(quote, outBarSize) to aggregate before calling Add(quote) would do it, keep some separation of concerns. This might be similar to or combined with #670

[mihakralj]

Let me study your new class system some more first.
Btw, did you know that you can rewrite SMA to use iterator too? See the formula for the value of next SMA item here: https://mihakralj.github.io/QuanTAlib/#/SMA

[DaveSkender]

I was thinking about the SMA increment and I went with an indexer on the existing quotes List, a by reference approach, mostly to avoid having to write new memory. I figured if I make Increment a public method, this still works if someone only provides the windowed quotes, albeit less proficiently than the internal data cache.

An overload to simply average the whole provided quotes might be helpful too, in that public case. Not sure how useful. Too much abstraction and they may as well just write their own code.

// would assume lookback period == array length
public static double Increment(
        List<(DateTime Date, double Value)> values)
    { … }