Range bars vs. point(original)  [SOLVED]

Questions about MultiCharts and user contributed studies.
davidcolin
Posts: 4
Joined: 25 Sep 2016
Has thanked: 2 times

Range bars vs. point(original)

Postby davidcolin » 25 Sep 2016

Can someone tell me the difference between Multicharts' range bars ("points" as chosen in the format instrument > settings tab) and the x points(original) bars?

My observation is that the range bars all have the exact same range but that the points(original) bars do not. The open to close values of points(original) are all pretty much equal however there is frequently extra range built into the bars (bar highs and lows) which can't really be explained as large extra ticks, because the range is often double what you specified. I don't get it.

Are either of these bars using synthetic data? Can they reliably be used for backtesting? I recall TS's Kase bars gave unrealistically positive results which rendered them useless for backtesting however I can't recall why.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Range bars vs. point(original)

Postby Henry MultiСharts » 26 Sep 2016

Hello davidcolin,

“Point Original” bars differ from “Point” bars in MultiCharts.

When “Point Original” resolution is used:
The bar closes when the following condition is met:
modulus |Open*PriceScale - Close*PriceScale| >= chart resolution (a tick is not split, it is completely included in the bar, even if the price difference exceeds the chart resolution).

As for the "Point" resolution:
The bar closes when the condition is met:
modulus |High - Low| > chart resolution * (MinMovement / PriceScale)
• price difference in points is equal to selected chart resolution
• a new bar is formed from the remainder of tick price with MinMovement*PriceScale offset
• the volume is allocated proportionally between all bars built from the tick, i.e. summarized tick volume is equal to summarized bars volume
• one tick is included into a bar only once, i.e. summarized tick amount is equals to summarized amount of TotalTicks in bars (if the tick is split up-it will be calculated in the first bar, it will not be calculated in the next bars)

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Re: Range bars vs. point(original)

Postby TJ » 26 Sep 2016

Hello davidcolin,

“Point Original” bars differ from “Point” bars in MultiCharts.

When “Point Original” resolution is used:
The bar closes when the following condition is met:
modulus |Open*PriceScale - Close*PriceScale| >= chart resolution (a tick is not split, it is completely included in the bar, even if the price difference exceeds the chart resolution).

As for the "Point" resolution:
The bar closes when the condition is met:
modulus |High - Low| > chart resolution * (MinMovement / PriceScale)
• price difference in points is equal to selected chart resolution
• a new bar is formed from the remainder of tick price with MinMovement*PriceScale offset
• the volume is allocated proportionally between all bars built from the tick, i.e. summarized tick volume is equal to summarized bars volume
• one tick is included into a bar only once, i.e. summarized tick amount is equals to summarized amount of TotalTicks in bars (if the tick is split up-it will be calculated in the first bar, it will not be calculated in the next bars)

Henry: Do you have a link to wiki on this definition? I remember you explained it in this forum before. I tried to find either and the search engine failed me miserably.

davidcolin
Posts: 4
Joined: 25 Sep 2016
Has thanked: 2 times

Re: Range bars vs. point(original)

Postby davidcolin » 26 Sep 2016

Thank you Henry. Has anyone reported unrealistic results when backtesting with either of these bar types? I don't remember why TS Kase bars gave "false positive" backtest results.

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Re: Range bars vs. point(original)

Postby TJ » 27 Sep 2016

Thank you Henry. Has anyone reported unrealistic results when backtesting with either of these bar types? I don't remember why TS Kase bars gave "false positive" backtest results.

Range type bars are NEVER good for backtests,
because range bar by definition is a hindsight.
When you backtest a range bar, the hindsight becomes normalized.
The result maybe pleasing because optimization will form fit the curve for you.
But normalized hindsight is not real;
it will be very difficult to duplicate your optimized results based on
normalized hindsight onto a moving target, as in real life trading.

YMMV

davidcolin
Posts: 4
Joined: 25 Sep 2016
Has thanked: 2 times

Re: Range bars vs. point(original)

Postby davidcolin » 27 Sep 2016

How are range bars a hindsight? They plot in real time just like any other time based bar.

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Re: Range bars vs. point(original)  [SOLVED]

Postby TJ » 27 Sep 2016

How are range bars a hindsight? They plot in real time just like any other time based bar.

For time-based bars or volume-based bars, there is a specific end-point for each bar:
eg. either a time lapse has reached, or a volume count is attained.

For range bars, the end-point is a moving target.
You will need an opening tick that is outside of the range to trigger a new bar.
In another word, the only time you know the bar is closed -- is in hindsight.


There are lots of articles on the internet describing the pros and cons of backtesting range bar. I am sure they can do a better job explaining.

Good luck.

Jad
Posts: 92
Joined: 15 Jun 2014
Has thanked: 13 times
Been thanked: 21 times

Re: Range bars vs. point(original)

Postby Jad » 29 Sep 2016

For range bars, the end-point is a moving target.
Yes, the bar's end-points may be moving targets but that doesn't mean that there is no specific end point for each bar.
It only means that the specific end points can change from tick to tick.

The specificity (or exact prices) for the bar's extremes (and by extension, the price beyond which will start a new bar) can still be determined ahead of time rather than ONLY in hindsight.
You just have to recalculate them on very tick.

e.g.
Low + Range = THE Final High of the bar (if its current Low is not exceeded) and
High - Range = THE Final Low of the bar (if its current High is not exceeded).

Add/Subtract one Tick (respectively) to obtain the price, at or beyond which, a new bar will start.

Note: In MC, IOG will be required to be able to place orders at these prices ahead of time but that's entirely due to a Multicharts constraint. That in itself does not mean that the High/Low is only possible to determine in hindsight.


Return to “MultiCharts”