Dinapoli preferred Detrended-Price-Oscillator (DDPO)

[fortcentral]

Indicator: Dinapoli preferred Detrended-Price-Oscillator (DDPO)
The oscillator indicates level of overbought (OB) and oversold (OS). The DDPO calculation produces a signal line that oscillates above and below zero to indicate level of OB/OS.

Regards,
Fortcentral

----------------------------------------------------------------------------
Oscillator Display Customisation:
The calculated oscillator signal is displayed in a panel at the bottom of a price chart, with the following (automated) horizontal display lines to provide a visual guide of the oscillator displacement from the zero line:
1) the (horizontal) zero line
2) the maximum oscillator positive and negative value corresponding to the maximum overbought (max.OB) and minimum oversold (min.OS) value within a "z.period" oscillator calculation lookback period (described further below).
3) The "avg.max.OB" line, which is the "average maximum overbought level"; derived from the average value of "x" number of the highest oscillator peak values chosen in (descending) order of magnitude, within a defined "z.period" oscillator calculation lookback period (described further below).
4) The "avg.min.OS", which is the "average minimum oversold level"; derived from the average of "y" number of the lowest oscillator trough values chosen in ascending order of magnitude within the defined "z.period" oscillator lookback period (described further below).
5) A dotted line showing a user-definable-percentage "a%" value of the "avg.max.ob" and the "avg.min.os" value within a "z.period" oscillator calculation lookback period (described further below).
------------------------------------------------------------------------------

--> Price Source: Bar

--> User Input Parameters:
1) "n.period" is total number of price bars used in the oscillator calculation, i.e. the simple moving average (SMA) lookback period. It is "7" by default but can be any integer number.
2) "z.period" is the lookback period within the oscillator calculation to generate display of max/min/average values of OB/OS levels. Default is "135" periods.
3) "Price" option for oscillator calculation. User-definable to use either the High, the Low or the Closing Price of each price-bar as the basis for the oscillator calculation. Default is "closing price" of each bar.
4) "SF" is a scaling factor; an Integer which can be a decimal number also. Default value is "1.0". This parameter scales the DDPO oscillator line to make it suitable for display across various instruments.
5) "x" is the number of the highest peaks in the DDPO line (in descending order of magnitude) within the "z.period" lookback of the oscillator calculation, used to derive the "avg.max.OB" (as described above) value. Default value is "3" peaks.
6) "y" is the number of the lowest troughs in the DDPO line (in asceding order of magnitude - as they are negative values) within the "z.period" lookback of the oscillator calculation, used to derive the "avg.min.OS" (as described above) value. Default value is "3".
7) "a%" -> this is a percentage value of "avg.max.OB" and "avg.min.OS" within the "z.period" lookback of the oscillator calculation, displayed as dotted horizontal guide lines. Default value is "60%" of "avg.max.OB" and "60% of "avg.min.OS"
8) Option to choose line thickness, style and colour for DDPO oscillator line display
9) Option to turn on display and choose colour and line style for "max.OB", "min.OS", "avg.max.OB", "avg.min.OS" and "a%" lines within oscillator display panel.

************************************************************************************
--> Dinapoli preferred Detrended-Price-Oscillator (DDPO) Calculation:
DDPO(time) = SF*[Price(time)-(n.period.SMA of Price)]

************************************************************************************

Notes:
(1) DDPO(time) is the current time-period Dinapoli preferred Detrended-Price-Oscillator value
(2) SF is the scaling factor as defined above
(3) Price(time) is the current time-period price
(4) "n.period.SMA" is the "n.period" simple moving average value of price. SMA is the simple moving average calculation of the last n-prices inclusive of the current price, i.e. n.period.SMA = {[P(1)+P(2)+P(3)+......+P(n)]/n}.

[Apprentice]

I have a problem understanding points 5-9.
Do you have any example, excel calculation or other platform code implementations?

Try this version.
viewtopic.php?f=17&t=67270

In my example, have simply the calculation a bit, min/max of Detrended-Price-Oscillator value was used for normalization.

[fortcentral]

OK, I was perhaps trying to add in too much in one go and I can see why it was confusing. So maybe we can start this process again with a clean-slate and build in stages to get to the final result.

The most important point of this oscillator is that it is not normalised! It displays the raw output and thus overcomes the limitation of many normalised oscillators which do not have much room to move when the oscillator reaches overbought/oversold territory, even though price may go much higher/lower respectively afterwards.

So the basic oscillator formula to begin with is:
*********************************************************************
DDPO(time) = SF*[Price(time)-(n.period.SMA of Price)]
**********************************************************************

Where:
(1) DDPO(time) is the current time-period Dinapoli preferred Detrended-Price-Oscillator value
(2) SF is the scaling factor as defined above. Integer number (including decimal) -> (+/-) 10000
(3) Price(time) is the current time-period price
(4) "n.period.SMA" is the "n.period" simple moving average value of price. SMA is the simple moving average calculation of the last n-prices inclusive of the current price, i.e. n.period.SMA = {[P(1)+P(2)+P(3)+......+P(n)]/n}.
(5) Option to use the "close", "high" or "low" pricepoint of a "price bar" for the calculation as each of the three price sources produce an oscillator line with different characteristics, which is useful for analysing different characteristics of price action.

Hope we can begin with just getting this on and then adding the next few layers one at a time and that this process is a little clearer.

Thanks

[Apprentice]

This is clear.
Can you clarify the following?

5) "x" is the number of the highest peaks in the DDPO line (in descending order of magnitude) within the "z.period" lookback of the oscillator calculation, used to derive the "avg.max.OB" (as described above) value. Default value is "3" peaks.
6) "y" is the number of the lowest troughs in the DDPO line (in asceding order of magnitude - as they are negative values) within the "z.period" lookback of the oscillator calculation, used to derive the "avg.min.OS" (as described above) value. Default value is "3".
7) "a%" -> this is a percentage value of "avg.max.OB" and "avg.min.OS" within the "z.period" lookback of the oscillator calculation, displayed as dotted horizontal guide lines. Default value is "60%" of "avg.max.OB" and "60% of "avg.min.OS"
8) Option to choose line thickness, style and colour for DDPO oscillator line display
9) Option to turn on display and choose colour and line style for "max.OB", "min.OS", "avg.max.OB", "avg.min.OS" and "a%" lines within oscillator display panel.

[fortcentral]

Ok, so the next stage!

Points (5) and (6)
An example:
For a lookback period of say about the last six-month of daily price data, the detrended oscillator produces three "prominent peaks" - "100.2", "86.57" and "77.57" as shown in the attached graphic. Then, the "average.overbought" or "average.maximum" value will be the average value of the three peaks -> (100.2+86.57+77.57)/3=88.11 --> this is for the most recent time-period; i.e. over the last six months of oscillator data (lookback).

Similarly for the troughs - use for example "3" of the most "prominent troughs" to calculate the "average.oversold" or the "average.minimum" value of oscillator extremes, which is relevant for the current time period.

The reason for specifying "x" and "y" is that sometimes there are double tops or bottoms in close succession within the oscillator and it tends to skew the automatically derived "average.overbought" or "average.oversold" calculation. Hence it would be nice to have the option to increase or decrease the number of peaks or troughs used in the average calculation depending on the instrument and how the oscillator is behaving.

Analysis based on the current oscillator value is most relevant when seen in perspective of recent oscillator data - hence the lookback of say 135 bars - a little over 6 months when looking at daily bars and 5 trading days/week (note the "z.period' lookback).

The "maximum overbought value" or the "oscillator maximum" in the attached graphic was "100.2" and the "maximum oversold" value or the "oscillator minimum" in the lookback period of approximately 6 months was "-144.8". It is always good to keep these maximum/minimum values in focus as big thrusting moves produce oscillator movement, which often react back to these "historical oscillator extreme values".

In excel i normally use the [large(range,value)] or [small(range,value)] to get the required peaks or troughs within a calculated range. The average of three peaks in a range for example could be calculated in excel, like so ->
Average[large(range,1),large(range,2),large(range,3)] --> this would be "average.overbought"

If it is too hard to program this automatically in lua (as I do not know the language) then this can be left to a manual method - estimating the average from the visible oscillator peaks and troughs and then manually inserting a horizontal line on the display panel (if required) to indicate a critical level of interest.

Point (7)

The reason for calculating the most recent "average.overbought" or "average.maximum" and "average.oversold" or "average.minimum" values is, that a price move potentially starts running out of steam when the current oscillator value reaches around 65% of "average.overbought" or "average.oversold" and by the time the current oscillator value has reached 90% of "average.overbought" or "average.oversold"; it is a good place to close the trade and take profits.

The "a%" value noted in point(7) is a calculation of a percentage of the "average.overbought" or the "average.oversold" value, so for example, calculating the 60% value of the "average.overbought" level in the above example -> i.e. (0.6)*(88.11)=52.87

An automated display of a horizontal line for example at this 60% of "average.overbought" value of the oscillator, i.e. at "52.87" would visually make it easier to gauge the risk of a trade by looking at the oscillator panel -> if the oscillator is already above 60% "average.overbought" level (or above 52.87 in example), and there has been a thrust-up, then the following move is likely going to run out of steam soon and it may not be worth taking the trade.

Points (8) and (9) are more related to the option of choosing the look and feel of the display. Depending upon the screen and space - if there is very little room then to economise it would be good to switch display line options "off" if required - as sometimes less is more!

Hope this explanation makes it clearer than before!

Regards,
Fortcentral

[Apprentice]

Your request is added to the development list under Id Number 4427

[fortcentral]

Thank you!

[Apprentice]

Something like this?

ddpo v4.lua

(7.58 KiB) Downloaded 461 times

[fortcentral]

Dear Apprentice,
Thank you so much for coding this up! The oscillator is generating the correct values overall - hence I really appreciate your help! This is a simple but a really useful indicator. Some further comments below.

Firstly, I wanted to confirm a basic question re price source. As tick data is different in form to price bar data, and the current indicator uses price source as "core.Tick", I was hoping to clarify if any difference is experienced by switching between "price.bar" and "price.tick" as a source. The calculations seem to be coming out fine - so this is just for information on how the two price source commands in lua are different?

Also I played around with different settings of the indicator to backtest and have a few comments for changes/tweaks:

1) It appears that the current "OB%" (60%.high) and the "OS%" (60%.low) values may be switched in the oscillator display, i.e. the high value is appearing as the (negative) low and the low value is appearing as the (positive) high. I have tried a few different settings and it is consistently inverted. Could you please check?

Also the basis for calculating the 60% line needs a slight change. Is it possible to change this line (i.e. the OB% and OS% line) as percentage.% (60% default) of the absolute-maximum-displacement (whether positive or negative) within the lookback period. Currently it is based on the average of the peaks and it needs to change to being calculated as a percentage of the largest displacement (high/low) within the lookback period. I have confirmation from the Dinapoli team on this.

So the result will be two lines as they are displaying now, with the following changes:
i) +60% line being drawn at +0.6*(maximum-absolute-value of displacement within the lookback period)
ii) -60% line being drawn at -0.6*(maximum-absolute-value of displacement within the lookback period)

From the example in the previously attached graphic, the "max.high" was "100.2" and the "min.low" was "-144.8". Hence the largest "absolute-value" of the displacement in the lookback period is "144.8". Therefore:
-> the +60% OB line is now calculated at [0.6*abs(-144.8)]=[0.6*144.8]=(86.88)
-> the -60% OS line is now calculated at [-0.6*abs(-144.8)]=[-0.6*144.8]=(-86.88)

Please retain the code for the "average.overbought" and the "average.oversold" calculations, as these values are very useful to have.

2) Also, the current DDPO Oscillator calculation seems to be rounding off after 4 decimal places. Is there a way to retain upto 8 decimal calculation data to reduce rounding errors? Not sure if there is a default restriction in lua which limits this? Ofcourse if the scaling factor is increased then greater detail is captured, which helps reduce rounding errors. For example scaling at SF=1.0, the DDPO might return a value of 0.0028, however when scaling factor is increased to SF=10,000 the following data would be returned 27.7286. The extra data helps reduce rounding errors, which will help in increasing overall accuracy of the oscillator output.

3) With regards to the oscillator calculation, an error is also being introduced at the beginning when the SMA data is not (yet) available. As SMA calculation is not beginning until the specified SMA-period is reached, so for example at Bar no. 7 for a 7-day SMA -> the oscillator calculation is returning just the price as the oscillator value for these periods (as the SMA value is zero). In many cases the price value is significantly larger than the oscillator value. It would be good to begin oscillator calculation, once the SMA data is available also from the price chart - e.g. at the 7th data point where a 7-day SMA is specified for the oscillator calculation. Can this please be fixed?

4) It would also be very nice to have a printed report at the top of the indicator panel, which displays the current values of:
i) Oscillator value and settings (current period value, instrument, price source, scaling factor, lookback period, starting date for lookback) - first three are already displaying. The starting date (or this could be a vertical line in the panel), would especially provide a quick way to judge where the current price-period lookback period is starting/ending. This will allow a quick judgement call to be made on whether the size of the specified lookback period is sufficient for the instrument and the time series.
ii) The current Max.overbought/Min.oversold oscillator displacement values in lookback period. At the moment it is represented by the red lines, which are very useful also as a visual guide.
iii) The current average.overbought/average.oversold values in the lookback period
iv) The current +60%/-60% values. Again the dotted display lines for these are also very useful.

The "current" values of the above parameters in Point (4) will provide a ready reference at any time to manually run other checks/calculations, during an ongoing trade. Otherwise the only way to estimate some of these, particularly the average.ob and average.os are to run the calculation manually from price data.

[Apprentice]

As we use core.Tick as a source, user can select any of available source (High, Low, Open, Close...)