NexusFi: Find Your Edge


Home Menu

 





Tip for backtesting on Renko charts


Discussion in NinjaTrader

Updated
      Top Posters
    1. looks_one cpi65 with 10 posts (0 thanks)
    2. looks_two Zoethecus with 7 posts (1 thanks)
    3. looks_3 gregid with 6 posts (11 thanks)
    4. looks_4 aslan with 6 posts (9 thanks)
      Best Posters
    1. looks_one traderlange with 7 thanks per post
    2. looks_two Seberbach with 2.3 thanks per post
    3. looks_3 gregid with 1.8 thanks per post
    4. looks_4 aslan with 1.5 thanks per post
    1. trending_up 34,728 views
    2. thumb_up 43 thanks given
    3. group 18 followers
    1. forum 44 posts
    2. attach_file 2 attachments




 
 

Tip for backtesting on Renko charts

 
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
Posts: 1,145 since Aug 2009


aslan View Post
Perhaps expose would be better than solve? lol

Your results are exactly what I would expect. Everyone trys Renko, and is certain the grail has been uncovered, only to loss when they go live. If you can find a strat that works with BetterRenko, then it should match when you go live. At least that is the theory.

I see no reason why this should be any better than the other bars that test with some degree of accuracy but I'll welcome another one to the family.

Bars in and of themselves do not provide an edge, no more than money management does.

Despite the Nike commercials, the shoes (bars) won't make you a better player (trader). Successful trading is not about the bars.


Can you help answer these questions
from other members on NexusFi?
NexusFi Journal Challenge - April 2024
Feedback and Announcements
ZombieSqueeze
Platforms and Indicators
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
New Micros: Ultra 10-Year & Ultra T-Bond -- Live Now
Treasury Notes and Bonds
Better Renko Gaps
The Elite Circle
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Get funded firms 2023/2024 - Any recommendations or word …
61 thanks
Funded Trader platforms
38 thanks
NexusFi site changelog and issues/problem reporting
27 thanks
GFIs1 1 DAX trade per day journal
18 thanks
The Program
18 thanks
 
 
aslan's Avatar
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
Posts: 625 since Jan 2010
Thanks Given: 356
Thanks Received: 1,127


Zoethecus View Post
I see no reason why this should be any better than the other bars that test with some degree of accuracy but I'll welcome another one to the family.

Bars in and of themselves do not provide an edge, no more than money management does.

Despite the Nike commercials, the shoes (bars) won't make you a better player (trader). Successful trading is not about the bars.

MJ did not play barefoot

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.

 
 
gregid's Avatar
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
Posts: 650 since Aug 2009
Thanks Given: 320
Thanks Received: 623


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?

Thanks again!

EDIT: I've just noticed your original thread about BetterRenko where you address my gap concern.

Started this thread
 
 Seberbach 
Midland, Michigan USA
 
Experience: Advanced
Platform: TradeStation, Biocomp
Trading: TF
Posts: 21 since Aug 2010
Thanks Given: 71
Thanks Received: 22

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.

Thanked by:
 
 
aslan's Avatar
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
Posts: 625 since Jan 2010
Thanks Given: 356
Thanks Received: 1,127


Seberbach View Post
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.

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.


Quoting 
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. 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.

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.


Quoting 
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.

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.


Quoting 
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.

Again, this is exactly what BetterRenko does.

Thanked by:
 
 
RJay's Avatar
 RJay 
Hartford, CT. USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: AMP/CQG, Kinetick
Trading: RTY
Posts: 682 since Jun 2009
Thanks Given: 757
Thanks Received: 787


Seberbach View Post
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.

Hi Seberbach,

I see this "gaps" thing a little differently. I hope you won't mind my counterpoint.

Should I draw the following conclusions from your explanation.

--------------------------------------------------------------------------------------

Price gaps that occur inside bars while bars are building are OK.

Price gaps that occur between bars are not.

--------------------------------------------------------------------------------------

Is that correct???

Thanks,

RJay

 
 
aslan's Avatar
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
Posts: 625 since Jan 2010
Thanks Given: 356
Thanks Received: 1,127


RJay View Post
Price gaps that occur inside bars while bars are building are OK.

Price gaps that occur between bars are not.

YES!

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.

Thanked by:
 
 Seberbach 
Midland, Michigan USA
 
Experience: Advanced
Platform: TradeStation, Biocomp
Trading: TF
Posts: 21 since Aug 2010
Thanks Given: 71
Thanks Received: 22


RJay View Post
Hi Seberbach,

I see this "gaps" thing a little differently. I hope you won't mind my counterpoint.

Should I draw the following conclusions from your explanation.

--------------------------------------------------------------------------------------

Price gaps that occur inside bars while bars are building are OK.

Price gaps that occur between bars are not.

--------------------------------------------------------------------------------------

Is that correct???

Thanks,

RJay



As usual in this field, yes and no.

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!

Thanked by:
 
 jlwade123   is a Vendor
 
Posts: 929 since Oct 2012
Thanks Given: 684
Thanks Received: 897


gregid View Post
Sam, I agree with 100% of what you wrote, but I think you are arguing against something I never claimed… but maybe I didn’t make it clear initially.

My original point was (and still is) “for backtesting purposes”. I never said I recommend using limit orders in live strategies as like with every type of order there are some pros and cons of every one of them and the decision which one to use should be made taking into consideration all possible ramifications (and you pointed out very well what would have to be considered for using Limit Orders while trading live)

So to rephrase and specify my initial point:

The way that market orders work for historical trades (and backtesting) is the order is placed at the Open of new bar. But because the Open of a new bar for renko bars is redrawn – the final Open is drawn only after the Close of the new bar is known, my proposed solution is to use Close[0] instead of Open[NewBar] for entry (when historical or backtesting).
In order to achieve it I suggest simulating MarketOrders with LimitOrders as in the post #1.

Few notes:
* The original NT6.5 SbSRenko (with long bars on reversal) doesn’t need this solution as the Open[NewBar]=Close[0] (I haven’t checked this yet – just an assumption)

* The suggested solution doesn’t take into consideration the slippage. If you decide to include slippage in your strategy, you would probably need to amend the limitprice to something like:
 
Code
                            
EnterLongLimit(Close[0]-(Slippage*TickSize),"entry1");

EnterShortLimit(Close[0]+(Slippage*TickSize),"entry1"); 


And to recap:
You don’t need to do simulate MarketOrders in live strategy – it is helpful only for historical trades and bactesting!!!
And: No backtest is comparable to live feed test!!!

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.

Follow me on Twitter
 
 jlwade123   is a Vendor
 
Posts: 929 since Oct 2012
Thanks Given: 684
Thanks Received: 897



Big Mike View Post
You can't do the slippage like that, in my opinion. Instead, use the NT menu itself and input at least 1 tick of slippage for the limit order.

The problem is, NT doesn't handle limit orders very well (in my experience). Just be sure you do a lot of 'live' trading (on sim) with the strategy. Trade it 'live' for a day or two, then go back and run a backtest for identical period. Do the results match, or are there "unexplainable" differences. That will be your sign

Mike

I will soon be going through the process of backtesting Renko limit orders and appreciate the heads up on the 1 tick slippage. Thanks,

Follow me on Twitter

 



Last Updated on March 8, 2019


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts