How range, momentum, kase and renko should be implemented

Questions about MultiCharts and user contributed studies.
Posts: 96
Joined: 26 May 2009
Has thanked: 6 times
Been thanked: 18 times

How range, momentum, kase and renko should be implemented

Postby tekram » 26 Oct 2009

Here is an excerpt from a discussion on another forum on how some of these specialized bar types should be implemented. Attached please find the original PDF file contributed by bluelagoon.
by bluelagoon.
The way it should be done:
Do in depth research first -> understand and generalize the problem into 'any bar is just a bar with different bar ending criteria' -> implement the concept as code -> the concept simplifies implementation -> proper coding guarantees automatic support of IOG, LIBB, data integrity -> no problems, no complaints -> furthermore the concept allows to easily add many more bar types in the future or -> better yet integrate the concept into EL custom bar concept where users code their own bars, i.e. instead of offering canned bars go further offer with innovative framework to compile your own bars.

TS should recode those types of bars, throw out the existing implementation, use the bar ending criteria concept + factor in user feedback on how to handle the finer details ( session start bar resets, gaps, discussed in details, etc ), instead of trying to fix the current implementation or waiting on the user vote count to add those "extra" features.

Below in the attached pdf file, I'm laying out some points regarding how to implement range, momentum, kase and renko bars properly so that all potential problems are eliminated. It is exceedingly frustrating because of 1. the multiple unnecessary problems that are introduced in this implementation and 2. simple solutions that can fix most of those problems that are not being followed.

PROBLEMS AND SOLUTIONS for range, mom, kase, renko bars:

1. "Session start bar resets" solves the problem of different data on chart reload or first
bar date/time, else the "continuous" data in the range or mom or kase chart is dependent
on the first bar on the chart, as everything else computes from there, but if data is reset on
session breaks ( as normally done ) then integrity through the session is maintained, ie
data is same within session starting from days open tick through days closing tick, for
forex use 24 marker as reset point... data then can be safely kept in TS cache with not
need to recompile the bars from FIRST BAR IN THE CHART each time you create a
new chart... Otherwise, if we take the example of current range bar implementation with
no bar resets on new session, all range bar data becomes dependent on the first bar loaded
into the chart, ie if you change first date in chart then first bar changes and that changes
the whole range bar data series going forward, this is substandard implementation, data
can't be kept in cache because it's dependent on first bar in the chart... historical data has
to be recomputed each time data interval is 'days in chart' is rolled forward since first bar
in the chart is changing each time you roll the dates forward. In comparison to that if you
reset range, mom, kase, renko bars on each session start - i.e. start compiling data from
new session start, then all problems automatically go away: historical data is same for all
days in chart as it's not dependent on first day of chart, you can safely store data in cache
and reuse it in the future without having to recompile it, real time and historical data will
always match, end of day exits will always work, open and close session ticks are
maintained, it's then easier to show session breaks.
I have no idea who at TS came up
with the idea of having continuity in range or momentum data from session to session,
that one idea introduced the whole series of problems... NEEDS TO BE RECODED.

2. "Bar ending criteria" concept solves the problem of forward data snooping and data
inconsistencies, you build the bar until your bar ending condition fires, then you start
building new bar, how complicated is that? You can then code whatever simple or
complicated bar ending conditions in TS and the rest of the bar building algo becomes
simple, you simply continue compiling bars until bar ending criteria fires and which point
you start building new bar going forward.

Bar ending criteria for different types of bars:
time bars: if bar duration >= N minutes or seconds or milliseconds then end_bar = true
tick bars: if N ticks in bar >= N then end_bar = true
volume bars: if bar Volume >= N then end_bar = true
range ( and variation mom and kase ) bars: if Range = High - Low of the bar >= X then
end_bar = true
renko bars ( various version o-c or c-c[1] ) bars: if o-c of the bar >= X then end_bar =
ANY TYPE OF BARS: if "bar ending criteria" >= Z then end_bar = true
Thus who cares what type of bar it is: you can build a framework for any type of bar
where you just plug in any bar ending criteria ( simple or complex ) and it will build the
bar based on that...

continues on the PDF... definition of bars types. ... c_ID=89104
mom renko kase bars opr06MMV.pdf
(25.21 KiB) Downloaded 141 times

glen demarco
Posts: 35
Joined: 16 Nov 2009

Postby glen demarco » 16 Nov 2009

I'm a big fan of range and renko type bars as all bar intervals are not equat. An hours worth of trading during lunnch time and an hours worth of trading at 10:00 are qute different. Most systems based on technica indicators usually generate the worst signals during lunchtime, as the indicators get skewed do to lact of activity.

I havew found the percentage profitable of systems based on tick, range, Renko and point and figure are much higher. The problem is esignal for example although allowing Renko charts have had know bugs going back 5+ years that cannot be correxcted. Indicators drift and backtesting results are over inflated as the back tester "looks ahead" invalidating the results.


Return to “MultiCharts”