Measures pivots in an oscillator and flags if they are above a configurable size. Uses absolute size rather than just highest/lowest in a candle range.
Uses the total change in the Y axis, instead of a simple Williams pivot over a defined number of bars. In other words, it measures the size of the actual pivot, not just whether it happens to be the highest/lowest value in a range.
Measures the absolute, cumulative change both before and after the pivot, to avoid flagging mere kinks in trends.
The advantage is that absolute pivot size is, in some cases, precisely what we care about. A disadvantage is that it can take an arbitrary, perhaps long, time to confirm.
You can configure the threshold size of the pivot so that it finds large or small pivots.
Always returns a pivot high after a pivot low, then another pivot high and so on, in order. It never returns a high followed by a high, which simple indicators based on the ta.pivot() function can do.
@param chart_H_1 This must always be set to 1, unless you are using my HighTimeframeTiming library, in which case set it to the output of the function for a _HTF_H of 1.
@param chart_H_2 This must always be set to 2, unless you are using my HighTimeframeTiming library, in which case set it to the output of the function for a _HTF_H of 2.
@param _osc This is the oscillator float value.
@param _oscPivotSize This is the user setting for what counts as a big enough change to be a pivot.
@returns Information about the pivot that is likely to be useful in further calculations:
confirmPeak, confirmDip - whether the pivot was confirmed this bar
peakBarsBack, dipBarsBack - how many bars ago the actual peak or dip was
peakPrice, dipPrice - the value of the oscillator at the peak/dip
It also returns some internal variables, which are plotted in this library only for an understanding of how the function works.
debug_peakStartLevel, debug_dipStartLevel - The level of the currently active peak/dip
A large number of significant changes in V2.
Added a new, advanced function with very different pivot logic: f_osc_PivotsAndShoulders()
+ Ordinary pivots confirm later if price diverges. This means that if you get e.g., a potential peak, and then a lower peak in the oscillator and a higher close in price, the potential peak moves to be the next, divergent peak.
+ A new pivot type: shoulder pivots. Unlike ordinary pivots, which go in a strict order of peak-dip-peak-dip, one or more shoulder pivots can occur after a normal pivot of the same direction. So for example, if you get a normal peak confirmed by momentum and then a lower peak (a shoulder) in the oscillator and a higher close in price, you get an additional divergent peak.
+ Pivots and shoulders can be excluded by oscillator value.
+ Pivots of both types are confirmed by price as well as by momentum. This confirmation needs a close beyond the wick of the lowest/highest candle of the dip or peak. Confirmations are returned for momentum-only and for momentum plus price.
If you use a lower pivot size, you will get more shoulders, and with a larger pivot size, more ordinary pivots. If you use a smoothed oscillator value, like an average of RSI, you might not get any shoulders at all.
The peaks and dips that are confirmed by momentum go in strict order peak-dip-peak-dip (when the library function is called from an external script with default settings), as in the other functions. However, not all of them may be confirmed by price. Therefore, the peaks and dips that are confirmed by price do NOT go in strict order and this is by design.
Added a new, simpler function that doesn't force you to assign a bunch of dummy variables if all you care about is confirming a pivot: f_osc_PivotsLite()
Changed the HTF inputs to match my HighTimeframeSampling library: instead of the HighTimeframeTiming one: because I think it's much better. Instead of the inputs being chart bar offsets, they're now just floats.
For the f_osc_Pivots() function, if you use the HighTimeframeSampling library, supply _osc1In and _osc2In as the value of _osc 1 and 2 HTF bars back, respectively. Because of this change, the input order is completely different.
An example of using the HighTimeframeSampling to generate the right inputs is included, but commented out by default.
Changed the display options. You can now choose which function is displayed, and all information returned by that function is plotted. So, there's no use anymore for the show debug and show labels options and they've been removed.
The label text is now shorter - the number of bars in which the pivot was confirmed are simply shown in brackets ().
Minor update to the f_osc_PivotsAndShoulders() function: Added a new ouput _closestPivotLevel. This takes the value of the closest candidate dip or peak. If we're between looking for dips and peaks, takes the oscillator value. It is an intuitive rendering of the most interesting recent level. Can be useful for post-processing, if you'd like to, for example, treat extreme levels differently, rather than just filtering them out using the existing options.
⭐️ Pro scripts: simplecrypto.life/pro-scripts/
📗 Articles: simplecrypto.life/articles/
🙋Get help with Pinescript: simplecrypto.life/get-help-with-pinescript/
In true TradingView spirit, the author has published this Pine code as an open-source library so that other Pine programmers from our community can reuse it. Cheers to the author! You may use this library privately or in other open-source publications, but reuse of this code in a publication is governed by House Rules.
Copy the following line and paste it in your script.