ZigZag Indicator Non-Deterministic Behavior

[BlackBoxTradingGroup]

I found it incredibly confusing that the output_values array can be modified in place by the indicator.

This diabolical behavior could lead to catastrophic live trading performance since batch vs iterative input yield different results.

The behavior that I expected was that pivots would be added to the output_values array only AFTER they are confirmed to be pivots, given the min_trend_length.

It makes sense that users may want to see potential pivots in real time as they form, but the API doesn't expose any method to see once a pivot is confirmed.

Honestly, the entire API is not good for iterative input. When you add a new candle, the API should return a new Pivot or None. That would be the most intuitive approach. Not having these features has forced me to write smelly code like this:

    prev_len = len(self._zig_zag)
    self._zig_zag.add(ohlc)
    if (len(self._zig_zag) > prev_len) and prev_len > 1:
        new_swing = self._zig_zag[-2]  # get pivot only after it is confirmed
        print(new_swing, '@', str(ohlc.time))

I recommend that even if you don't change the indicator behavior that you at a minimum add some notes and warnings to the documentation about how to use the indicator. It took me an hour of debugging to figure out what was going on.

[nardew]

Thanks for feedback. I am open to discuss the API changes though it is not entirely clear to me what is your expectation for pivot to be "confirmed". If you assume that you start with a low pivot and after that the price keeps increasing (which currently leads to continuously updating new high pivot), when do you expect a new high pivot to be "confirmed"? Is it when next potential low pivot is identified (because only then you know that the high pivot cannot change anymore)?

Furthermore, if length of input and output values is to be equal and output values are Pivot or None, it is even more confusing because when pivot gets "confirmed" for a new input value, the actual pivot is one of the past candles. Should output value for that past candle get rewritten? Definitely not. Should output value for current input value when pivot gets confirmed simply refer to the past candle corresponding to the pivot? It could but then semantics of output values might be even more confusing. Another option is that each output value simply refers to last pivot (i.e. no None's).

If length of input and output values do not match, then a potential change is simply to add a pivot into the output values only once it gets confirmed.

I am still evaluating which approach is more natural (length of input and output values matching or not). Currently I am inclining to the latter option (lengths do not match) but probably include only confirmed pivots.

@BlackBoxTradingGroup if you have anything to add, feel free.