I hope someone that is all mechanical understands why some bars do and dont work. It is all about the data, not the visual format that the bar presents it. I could care less about the format of the bar unless it is helping me see something. The problem with many bars is that they are presenting one set of data to your strat that you can not actually act on, but your strat does not know that, and so generates great results even if you will go broke when you go live because the fills/slippage are horrible. Renkos are just one example of bars delivering bad data.
I am much more discretionary at this point, and bars do make a diff as you need to be able to read price. A classic Renko will take the noise out and show the swings, but you are not seeing all of the data. When you add that info back to the chart, you can get a much better read on what is really going on. To some, that may be completely useless.
This thread is about backtesting with Renko. In order to do that in an accurate way, you have to have good OHLCV data on each bar, otherwise you are just fooling yourself. That is what the BetterRenko tries to accomplish. I have had numerous people ask me about this, and I knew that the WickedRenko was not the answer as it repaints the open. BetterRenko takes the good parts of Sbs, Median, Classic, and Wicked, and builds on it to present the visual part and the data part in a way that should be useful to each intended audience.
The following 5 users say Thank You to aslan for this post:
Aslan – great work! I feel like you can read my mind – I was thinking about similar implementation for some time now but couldn’t come up with the right way of implementing it.
I am not sure if your BetterRenko addresses this issue (can’t check it now) but I think the next step in Renko evolution should be to somehow visualize the gap on the renko chart (without destroying the smoothing effect of renko).
So guys what do you think about it, any ideas on how to achieve that?
EDIT: I've just noticed your original thread about BetterRenko where you address my gap concern.
Last edited by gregid; August 9th, 2010 at 11:19 AM.
My opinion about showing gaps in renko is to tell the truth with the picture:
Show the gaps in the chart, even if the gaps mis-align the bricks from their neat quantized levels by leaving odd numbers of spaces between the highs and lows of them plotted in succession.
If you place a stop or limit price in the "next bar" after a setup in the prior bar, and it is in a gap, the chart bar should not intersect the stop or limit price because that price never existed and was therefore non executable in the back test. In real trading it is possible that your order could have filled a slot in that gap in a thin market, but the more likely failure is that there was insufficient liquidity, or the gap was between sessions. Those bricks should NEVER exist in the gaps, or the simple simulation will say your order back test was filled where the stop or limit intersected the brick even if that brick was a phantom brick.
In other words, let bricks "open" where price begins to actually exist as real historical trades, and count brick size continuations and reversals from there. The chart will not be so smooth, the bricks will not be aligned to the same modulo of ticks divided into the brick size, but you will get more realistic backtests because there are no executions in phantom bricks, or phantom portions of bricks.
That also means I prefer to start counting continuation and reversal ticks at the start of each session, or a certain consistent number of ticks offset from the opening tick. Usually as small gaps(skipped tick levels) appear during the session, the bricks become aligned by the gaps causing synchronous brick "opens" after a period of time.
The tops and bottoms of the bricks are like chandelier stops. In uptrend, the tops of bricks pull up the bottoms, in downtrend the bottoms pull down the tops. The difference is that price has to continue "size" or ticks more past the chandelier stops to make new tops (resistance lines) and pull up the bottoms (support lines) to brick size below the tops, in the case of up trend and vice versa in down trend.
That is how I ended up programming renko in TradeStation using tick charts. It does not agree with the built in TradeStation version, but is quite close most of the time in a liquid market with few gaps.
And the last tick before a new brick opens is the close, and the next tick is the open. Trade back tests operate on the ticks-within-the-bricks not necessarily the price lines forming the tops and bottoms of the bricks, which are really continuation stops and reversal stops of a "chandelier" stop and reverse algorithm.
The following user says Thank You to Seberbach for this post:
BetterRenko does this, but I chose to keep the alignment. By keeping the alignment, I did NOT insert any phantom data though. So, if there is a gap, and the brick hits the close and is not large enough, then you would get a truncated brick. Busting the alignment was an option, but I found the charts looked better when maintained.
Totally agree. BetterRenko maintains the correct open value as part of the bar, and the brick would only exist in the gap if it actually traded back across the gap.
BetterRenko starts fresh at the start of each session for two reasons. First, for backtesting and chart display you want the same bars regardless of what the start date of the data set is. Second, NT7 bar caching really requires it.
Within a bar, gaps can not be helped unless you want to create a new bar every time prices moves more than the TickSize away. All bar types have this issue, nothing you can really do.
If you gap outside the bar, a new bar is forced. That new bar has but one value when created, which is the tick that caused it to be created (OHLC all equal new tick value). Any other value is fictitious. As new ticks are processed for the new bar, the bar body could creep back into the gap, which is fine.
For backtesting purposes, the above is rather important.
The following user says Thank You to aslan for this post:
All gaps are correct, if they really happen. But a trading simulation which does not "look inside the brick" will not be correct if it assumes a trade could have been executed inside a gap that could not be shown for lack of specific information or had not been actually shown by adding that information. Using the tick by tick chart with renko overlay gives me the option to make erroneous simulation assumptions and compare the end result with a tick by tick correction of any such mistakes. If those mistakes luckily cancel out over time, or do not ruin an optimization too badly, that renko or whatever, can be considered a better one than a similar representation known to be grossly and dangerously invalid. Unfortunately computing the tick by tick corrected optimization is still way too slow for everyday use compared to using compressed formats directly. That is why I try to find a way to compress the charts without causing too much error in the back testing. I only hope to achieve using a compressed data format to result in "usefully correct" results in simulated historical testing. Then the approximate optimizations can be validated using the tick by tick corrected version, and also run that way in real time.
The discussion I saw happening here is about how you display time-compressed event based price data, and how much the short cuts made in a simulation of trading distort the reality of real time trading versus how much benefit there is in the improved visual clarity and speedups in computation from the data compression method used for displaying the data and simulating trades using the compressed data. This would apply to any type of chart you want to create, not just a standardized renko.
Gaps between price interval-sequential bars can be dealt with "correctly" here because the properties in the data object describing the "bar" can be made to reflect the between-bar gaps without adding new properties to that data object. There is no reason to misrepresent reality with phantom data for between bar gaps, but the renko bricks, even in OHLC bar or candlestick format, cannot show intra-brick gaps. I have considered coding color changes inside the bricks reflecting the volume-at-price, or crossing-counts of levels inside the bricks as a compact visual representation of compressed intra-bar information. Also this could represent a rough indication of probability-of-execution.
The gaps inside the bars can be handled only adding more properties (numbers) to the data records describing the bars. That is why I explained in my report as "experiences of someone who has actually tried to code" renko 'bars' what barriers I ran up against while trying to do so. I did in fact end up having to code a tick by tick chart with the graphically visualized logic of the renko data compression drawn on top of it just to get a clear visual representation of what I was trying to accomplish.
BTW, the idea of truncating bricks to show the gaps sounds interesting to me...I think I'll try it out! Good idea, why didn't I think of that before? Thanks!
The following user says Thank You to Seberbach for this post:
My strategy is based on closing price signals, so I should not see why executing on the close would be an algo I am developing with Renkos. I am going to review your thread to see if there are any other issues or flags I should be aware of. Thanks for this post.