Cumulative indicators and Recalc() method

[mihakralj]

I started to look deeper into indicators that require a reset/recalc method every day/hour/minute and don't require Period assignment as they are cumulative (until reset) . VWAP is most commonly used like this, but all other indicators (SMA, EMA, ATR...) are useful in strategies that use cumulative growth and periodic resets. Mind that the VWAP on the chart below is a SINGLE indicator that spans across the full duration of the chart:

Implementing this on all/most indicators would require several changes:

• recognizing when a indicator is not using a sliding window of size Period but is a Cumulative indicator; my suggestion is to use Period=0
• a new Reset() or Recalc() method would be needed for each indicator, triggering a reset of calculations, while still adding to the same output series
• a new parameter for indicators that indicates when to reset the series (day/hour/minute)

This would also solve the unfinished discussion of intra-period values; if indicator can be used as a cumulative one, EVERYTHING it calculates is intra-period as period is set to infinity... :-)

[DaveSkender]

I’m not sure I follow, are you referring to having a reset only on indicators like ADL, OBV, etc? I can see how those accumulating types would get unwieldy in extraordinarily long-running quotes histories; or in the case of VWAP where you may want it to reset every day or at the beginning of some calendar window or after a certain number of periods. Though, in the case of VWAP, I'd probably just utilize the quotes I wanted rather than trying to parse from a larger result set.

[mihakralj]

I have one running indicator (VWAP or EMA or whatever) - and let's say that such indicator has no given period. Instead of running a sliding window (of size Period), each next value provides smaller and smaller contribution to the series.

For example, EMA would be calculated as following:
0: d[0]
1: (2/2) * (d[1]-i[0]) + i[0]
2: (2/3) * (d[2]-i[1]) + i[1]
3: (2/4) * (d[3]-i[2]) + i[2]
4: (2/5) * (d[4]-i[3]) + i[3]
5: (2/6) * (d[5]-i[4]) + i[4]
6: (2/7) * (d[6]-i[5]) + i[5]
...
n: (2/n+1) * (d[n]-i[n-1]) + i[n-1]

Clearly, a cumulative EMA gets smaller and smaller contribution of the new data and would asymptotically drift to a flatline.

Same goes for most (all?) indicators - once the Period is omitted, indicators slowly flatline - unless they are reset, just like VWAP.

Let me create some examples with cumulative indicators (where period is ∞) and reset methods - if it works so well for VWAP, it might be useful for trading on minute-based datasets that span over several days and need a reset at the opening of each trading day.

[DaveSkender]

Yah, I think some visual aids would be helpful. A normal EMA would only converge to a flatline if the underlying quote price itself flatlined. I may be misunderstanding what you mean by "cumulative" EMA.

[DaveSkender]

I think what you’re suggesting is using something like windowSize in Pivot Points to reset the origin of accumulation. I can only envision that in a few cases.

[mihakralj]

ok, I created a Cumulative SMA() with Reset() method to demonstrate my thought process.
First, here is a cumulative SMA() [without a period] on 1,500 bars; each bar contributes less and less to the indicator, making the line asymptotically flatter and flatter; if you'd zoom to the left part of the chart, you'd see the cumulative SMA being much more responsive to new data points than the right side of the chart.

Second, here are SMA(period: 300) and SMA(reset: 300) - you can clearly see the difference between smooth/traditional SMA and jumpy SMA that resets to zero every 300 bars (imagine that the reset happens at the beginning of a month/day/hour); by the definition, SMA(with period) and SMA(cumulative with reset) converge to the same result at the end of each period:

I used SMA() here as it is very obvious how SMA() works within the period: it calculates the mean() of whatever bars are available, even before there are period number of bars. The same rule should apply to EMA, DEMA, and all other indicators.

[DaveSkender]

Just discovered markdown math syntax

[DaveSkender]

I think one way to narrow down your investigation is by two factors: 1) is it a price overlay (oscillators wouldn't make sense) and 2) is there a calendar context that has a purpose? For example, trading above or below the VWAP is a measure of how well you timed the trade during a trading day. Without that context, it'd be hard to say where this might be useful.

[mihakralj]

I'd call this "progressive" instead of "cumulative".

The process is the same as for the cumsum or cumprod

In general, when creating such functions in Numpy, it is done with ufunc.accumulate

Hence cumulative and not progressive. :-)

[mihakralj]

Just discovered markdown math syntax

Did you see the beginning of my indicator Calculation explanation here (and MD for it is here) - somehow Github doesn't render math MD syntax right)

[DaveSkender]

I prefer the mathematical and Webster's definition of cumulative over NumPy's monstrous aberration. Their cumsum sounds more like what you do to compute the Fibonacci sequence. Also, the math stuff 1) has to be bookended with $ for it to work on regular GitHub site rendering and 2) requires some work to get mathjax installed on your GitHub pages site.

[mihakralj]

these are three cumulative VWAP indicators - one is resetting every 2 minutes, one every 10 minutes and one every 30 minutes. Now I want to see if I also create cumulative SMA/EMA of OHLC4, how will these two lines (VWAP and EMA) interact...