Tip for backtesting on Renko charts - futures io
futures io



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 25,603 views
    2. thumb_up 43 thanks given
    3. group 18 followers
    1. forum 44 posts
    2. attach_file 2 attachments




Welcome to futures io: the largest futures trading community on the planet, with well over 125,000 members
  • Genuine reviews from real traders, not fake reviews from stealth vendors
  • Quality education from leading professional traders
  • We are a friendly, helpful, and positive community
  • We do not tolerate rude behavior, trolling, or vendors advertising in posts
  • We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community.  It's free and simple.

-- Big Mike, Site Administrator

(If you already have an account, login at the top of the page)

 
Search this Thread
 

Tip for backtesting on Renko charts

(login for full post details)
  #1 (permalink)
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
 
gregid's Avatar
 
Posts: 651 since Aug 2009
Thanks: 320 given, 620 received

All renko incarnations (NT Renko, MedianRenko, SBSRenko, WickedRenko) are unreliable for backtesting due to few issues. One of these issues is redrawing the "open" of the bar after the bar has formed.

In order to avoid the complications of the redraw:

Tip

Refrain from using Market Orders for backtesting purposes and replace all MARKET orders with LIMIT orders with LimitPrice = Close[0]
(this will simulate standard behaviour of market orders for CalculateOnBarClose = true)



Sample code:

 
Code
                            
//instead of using:
EnterLong("entry1");
//use:
EnterLongLimit(Close[0],"entry1");
 
 
//instead of using:
EnterShort("entry1");
//use:
EnterShortLimit(Close[0],"entry1"); 
Good luck backtesting!

Started this thread Reply With Quote
The following 6 users say Thank You to gregid for this post:

Journal Challenge April 2021 results (now extended!):
Competing for $1800 in prizes from Jigsaw
looks_oneMaking a Living with the Microsby sstheo
(599 thanks from 60 posts)
looks_twoSalao's Journalby Salao
(147 thanks from 26 posts)
looks_3Learning to Profit - A journey in algorithms and optionsby Syntax
(112 thanks from 26 posts)
looks_4Deetee’s DAX Trading Journal (time based)by Deetee
(94 thanks from 30 posts)
looks_5Maybe a little bit different journalby Malykubo
(46 thanks from 28 posts)
 
Best Threads (Most Thanked)
in the last 7 days on futures io
I finally blew up an account
490 thanks
The Crude Dude Oil Trading System
65 thanks
Spoo-nalysis ES e-mini futures S&P 500
63 thanks
The tiyfTradePlanFactory indicator
21 thanks
Are candlesticks patterns statistically significant?
19 thanks
 
(login for full post details)
  #3 (permalink)
ntmt
ca
 
 
Posts: 2 since Jul 2010
Thanks: 3 given, 0 received


Thank you for the tip!

Does it mean the following simple strategy will work as it supposed to on Wicked Renko charts?

HTML Code:
 protected override void Initialize()
        {
            SetProfitTarget("", CalculationMode.Ticks, 10);
            SetStopLoss("", CalculationMode.Ticks, 40, false);
            CalculateOnBarClose = true;
            EntriesPerDirection = 50; 
            EntryHandling = EntryHandling.UniqueEntries; 
        }

 protected override void OnBarUpdate()
        {
            if (Close[0] > Open[0])
            {
                EnterLongLimit(DefaultQuantity, Close[0], "L");
            }

            if (Close[0] < Open[0])
            {
                EnterShortLimit(DefaultQuantity, Close[0], "S");
            }
        }

Reply With Quote
 
(login for full post details)
  #4 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 since Aug 2009


ntmt View Post
Thank you for the tip!

Does it mean the following simple strategy will work as it supposed to on Wicked Renko charts?

HTML Code:
 protected override void Initialize()
        {
            SetProfitTarget("", CalculationMode.Ticks, 10);
            SetStopLoss("", CalculationMode.Ticks, 40, false);
            CalculateOnBarClose = true;
            EntriesPerDirection = 50; 
            EntryHandling = EntryHandling.UniqueEntries; 
        }
 
 protected override void OnBarUpdate()
        {
            if (Close[0] > Open[0])
            {
                EnterLongLimit(DefaultQuantity, Close[0], "L");
            }
 
            if (Close[0] < Open[0])
            {
                EnterShortLimit(DefaultQuantity, Close[0], "S");
            }
        }

Highly unlikely.

Reply With Quote
 
(login for full post details)
  #5 (permalink)
ntmt
ca
 
 
Posts: 2 since Jul 2010
Thanks: 3 given, 0 received


Zoethecus View Post
Highly unlikely.

Thank you for the reply.

I have read other threads about why backtesting on renko is not a good idea, but I thought the code above should function as close to reality as possible, since it make decisions only when the bar closes.

Could you give me a little more detailed explanation about why it won't?

Thanks again.

Reply With Quote
 
(login for full post details)
  #6 (permalink)
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
 
gregid's Avatar
 
Posts: 651 since Aug 2009
Thanks: 320 given, 620 received

I can't vouch for it but I believe it makes a difference. Please see the attached image and guess which chart uses Market orders and which uses Limit orders (everything else is the same in the simple strategy).

I highlighted just one fragment where you could see it straight away

Attached Thumbnails
Click image for larger version

Name:	NowGuess.png
Views:	882
Size:	313.0 KB
ID:	17379  
Started this thread Reply With Quote
The following user says Thank You to gregid for this post:
 
(login for full post details)
  #7 (permalink)
 sam028 
Site Moderator
 
 
sam028's Avatar
 
Posts: 3,676 since Jun 2009
Thanks: 3,791 given, 4,512 received


gregid View Post
I can't vouch for it but I believe it makes a difference. Please see the attached image and guess which chart uses Market orders and which uses Limit orders (everything else is the same in the simple strategy).

I highlighted just one fragment where you could see it straight away

There is differences in the charts you show, that's sure, and does it make sense ?

Limit orders are limit orders, so:
- you can't be sure they will be filled, so some additional logic is needed in the strategy itself:
-> the limit order is sent, but is it filled ?
-> if it's filled, at which price, so what are the consequences for the target/stop ?
-> if it's not filled x minutes/ticks/bar, what do to ? Cancel the order, change the limit price, ... ?
So the backtests results may look more accurate, but that doesn't mean you can have accurate results (or results similar to the backtests) when the strategy runs live.

The good test, imvho, is to run such strategy with a live feed, and see how it looks after few days, and then compared the live resulsts with the backtests results. And before this, add the MM parts described below, needed by limit orders.

Success requires no deodorant! (Sun Tzu)
Follow me on Twitter Reply With Quote
The following 3 users say Thank You to sam028 for this post:
 
(login for full post details)
  #8 (permalink)
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
 
gregid's Avatar
 
Posts: 651 since Aug 2009
Thanks: 320 given, 620 received

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!!!

Started this thread Reply With Quote
The following 3 users say Thank You to gregid for this post:
 
(login for full post details)
  #9 (permalink)
 Big Mike 
Site Administrator
Swing Trader
Data Scientist & DevOps
Manta, Ecuador
 
Experience: Advanced
Platform: Custom solution
Trading: Futures & Crypto
 
Big Mike's Avatar
 
Posts: 50,067 since Jun 2009
Thanks: 32,529 given, 98,483 received

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

We're here to help -- just ask

For the best trading education, watch our webinars
Searching for trading reviews? Review this list

Follow us on Twitter, YouTube, and Facebook

Support our community as an Elite Member:
https://futures.io/elite/

Visit other sites? Please spread the word about your experience with our community!
Follow me on Twitter Visit my futures io Trade Journal Reply With Quote
The following 5 users say Thank You to Big Mike for this post:
 
(login for full post details)
  #10 (permalink)
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
 
gregid's Avatar
 
Posts: 651 since Aug 2009
Thanks: 320 given, 620 received



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.

Mike

It wasn't my intention to add slippage this way, but to show how one would have to amend LimitOrder to simulate MarketOrder once the slippage is added (from NT menu or in the code in Initialize section).

I will write it again:

It is only about simulating MarketOrder for backtesting purposes


[sigh].... I feel like I will spend the rest of the day explaining what I wrote

Started this thread Reply With Quote
 
(login for full post details)
  #11 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received

Yo!

I asked a question but Big Mike closed it and told me to ask it here, so here goes:

Before we start, a few things I'd like to point out:

- I know how renko bars are formed, I am not an idiot. Please don't just say that they can't be used in real time, because they can under most market conditions.

- I will not execute any strategy that evolves in NinjaTrader, so any Limit/Market order problems in the NinjaTrader backtesting language are not applicable. I have slippage under wraps too.

- As I mentiond in the original question, I will be (or at least try to) using tick (trade, Bid X Ask) data for a significant period (say 1yr backtest, 5yr out of sample). In all liklihood I will be doing this in Matlab. Any stategy that does evolve will work from Matlab througbh to TT (after I have trded it live for a while for sanity).

So, the question is "has anybody tried this?".

CPI

Reply With Quote
 
(login for full post details)
  #12 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 since Aug 2009

I have not tried it.

What language are you using for this strat?

Reply With Quote
 
(login for full post details)
  #13 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received

Sorry Dude I don't understand - "what language"

??

Reply With Quote
 
(login for full post details)
  #14 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 since Aug 2009

Programming. Code.

Reply With Quote
 
(login for full post details)
  #15 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received

Then it'll all be in Matlab I guess (that should be fun eh!)...

Oh wait, you mean like C#, Jave etc?

I'll probably get someone else to do all the TT / Matlab integration stuff. I'm not a programmer, see. I just want the data in renko so I can do all my trader-stuff before handing it over to the boffins!

Reply With Quote
 
(login for full post details)
  #16 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 since Aug 2009


cpi65 View Post
Then it'll all be in Matlab I guess (that should be fun eh!)...


So, TT is the datafeed. What is the platform? Which ones support Matlab?

Reply With Quote
 
(login for full post details)
  #17 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


Zoethecus View Post
You planning on doing this yourself or hiring a consultant?

So, TT is the datafeed. What is the platform? Which ones support Matlab?

The basics I will do myself, because it is just a case of getting the data into matlab (I say that now, I have only really used matlab for econometrics etc so far, so I expect it to be a bit of a challenge).

Initially I will be using tick data so that won't come from TT, probably tickdataplus or somewhere. Then if I get somewhere I will get someone (mates of mine) to build up some simple program that uses TT data from Excel (i.e TT -> Excel (via RTD) -> Matlab based application -> My mince pies -> back into TT)

Then if we are still GOGOGO it'll go tt -> matlab -> Autotrader via COM (I think, I'm not a computer boff).

The computer bits of it I am not worried about, I've seen it done loads - its the strategy thats the important bit!!

Platform is X_Trader Pro

Reply With Quote
 
(login for full post details)
  #18 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 since Aug 2009

Is the strategy depended on Renko for success, or are you going to test other data series?

Reply With Quote
 
(login for full post details)
  #19 (permalink)
 Seberbach 
Midland, Michigan USA
 
Experience: Advanced
Platform: TradeStation, Biocomp
Trading: TF
 
Posts: 21 since Aug 2010
Thanks: 70 given, 22 received

I have coded strategies for Renko Bars in Easy language, but the bottom line is that what you have to code, tick by tick, is a series of "bars" which extend up to one brick-size above and below the bricks shown on your chart, so they really are not "Renko" bricks which are to be intercepted by your "set target" and "set stops" but TICKS! You can plot the renko bricks, but where the price actually moves can be in the open spaced above and below the "open" and "close" (until triggering a new brick by exceeding or touching as well one level past the "high" or "low" of the prior bricks. Since a backtester built using "reserved words" gets wrong information given said highs and lows, it cannot "see" those phantom non-defined price moves above and below the plotted "bricks", and it will give outrageously wrong estimates of your actual real time trades. It is more a matter of the stop orders (stop loss) and target orders (limit) which will execute outside of the bricks in real time that make your actual coding have little to do with those simplified visual "bricks" on the chart.

So, my little programming adventure with Renko ran way overtime, and was really a tick based strategy which happened to use renko construction retrace and continuation "rules" to give trading bar close setups only, and tick by tick monitoring between those new setups for the stop and target hits, and the cancelling or resetting of the stop and limit orders whenever each new brick closed out and the new brick started forming. That "forming" could finish, or close, one size above the prior high, or one size below the prior low before it completed, and was ambiguous the entire time in between. The chart may look like Renko, but reality will not look like Renko. And the profit will not look like renko profit ...at least it was a big disappointment for me in the end, but not a total waste of time, either. Since I do not know the programming of Ninja Trader, I do not know how it handles "look inside bars". I do know that EasyLanguage does NOT do it at all, let alone properly with Renko charts, Point and figure charts, and line break charts and TradeStation says it (back testing properly) is not supported for those chart types..

So to sum it up, if your renko strategy is working properly in the back test, your hypothetical executions, if they involve stops or targets, can occur, as they would in real time, anywhere in a three brick range before you see one little completed setup brick appear on the chart.

Reply With Quote
The following 4 users say Thank You to Seberbach for this post:
 
(login for full post details)
  #20 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


Zoethecus View Post
Is the strategy depended on Renko for success, or are you going to test other data series?

Yeah, I need the renko data.

Reply With Quote
 
(login for full post details)
  #21 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


Seberbach View Post
I have coded strategies for Renko Bars in Easy language, but the bottom line is that what you have to code, tick by tick, is a series of "bars" which extend up to one brick-size above and below the bricks shown on your chart, so they really are not "Renko" bricks which are to be intercepted by your "set target" and "set stops" but TICKS! You can plot the renko bricks, but where the price actually moves can be in the open spaced above and below the "open" and "close" (until triggering a new brick by exceeding or touching as well one level past the "high" or "low" of the prior bricks. Since a backtester built using "reserved words" gets wrong information given said highs and lows, it cannot "see" those phantom non-defined price moves above and below the plotted "bricks", and it will give outrageously wrong estimates of your actual real time trades. It is more a matter of the stop orders (stop loss) and target orders (limit) which will execute outside of the bricks in real time that make your actual coding have little to do with those simplified visual "bricks" on the chart.

So, my little programming adventure with Renko ran way overtime, and was really a tick based strategy which happened to use renko construction retrace and continuation "rules" to give trading bar close setups only, and tick by tick monitoring between those new setups for the stop and target hits, and the cancelling or resetting of the stop and limit orders whenever each new brick closed out and the new brick started forming. That "forming" could finish, or close, one size above the prior high, or one size below the prior low before it completed, and was ambiguous the entire time in between. The chart may look like Renko, but reality will not look like Renko. And the profit will not look like renko profit ...at least it was a big disappointment for me in the end, but not a total waste of time, either. Since I do not know the programming of Ninja Trader, I do not know how it handles "look inside bars". I do know that EasyLanguage does NOT do it at all, let alone properly with Renko charts, Point and figure charts, and line break charts and TradeStation says it (back testing properly) is not supported for those chart types..

So to sum it up, if your renko strategy is working properly in the back test, your hypothetical executions, if they involve stops or targets, can occur, as they would in real time, anywhere in a three brick range before you see one little completed setup brick appear on the chart.

Yo!

Interesting to hear about your experience in TradeStation. The strategy does not use set stop or limit orders, but generates market orders to open and close under the circumstances I specify. I have traded it in real time and it is perfectly possible, it's the backtesting bit thats a pain because I need the data in a granular format to get Renko bars that would have been created if i was walking it forward.

CPI

Reply With Quote
 
(login for full post details)
  #22 (permalink)
 Big Mike 
Site Administrator
Swing Trader
Data Scientist & DevOps
Manta, Ecuador
 
Experience: Advanced
Platform: Custom solution
Trading: Futures & Crypto
 
Big Mike's Avatar
 
Posts: 50,067 since Jun 2009
Thanks: 32,529 given, 98,483 received


cpi65 View Post
Yeah, I need the renko data.


cpi65 View Post
I need the data in a granular format to get Renko bars that would have been created

Which instrument? How much tick data do you need?

Mike

We're here to help -- just ask

For the best trading education, watch our webinars
Searching for trading reviews? Review this list

Follow us on Twitter, YouTube, and Facebook

Support our community as an Elite Member:
https://futures.io/elite/

Visit other sites? Please spread the word about your experience with our community!
Follow me on Twitter Visit my futures io Trade Journal Reply With Quote
 
(login for full post details)
  #23 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


Big Mike View Post
Which instrument? How much tick data do you need?

Mike

Yo Big Mike!

For the instrument, well I would obviously test each contract before it trades, but for the strategy to be implemented properly it needs to be a tight market with plenty of depth - because, say, I need to avoid contracts that could move by more than a renko box size without a single print on the tape "under normal market conditions" (obv. I am not going to trade it over NFP and so on), that is one of the problems with Renko on compressed data using close prices.

So I guess I am looking at FESX, FGBL, ES and ZN. Not all at one though LOL!

How much data? Well as much as I can get really, but should really go back before august 2007 (sub-prime writedowns, remember those LOL!).

Peace Out!

CPI

Reply With Quote
 
(login for full post details)
  #24 (permalink)
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
 
aslan's Avatar
 
Posts: 622 since Jan 2010
Thanks: 351 given, 1,116 received

I created a new bar type called BetterRenko, and there is a new thread for it here. It should solve backtesting issues with Renko.

Reply With Quote
The following user says Thank You to aslan for this post:
 
(login for full post details)
  #25 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


aslan View Post
I created a new bar type called BetterRenko, and there is a new thread for it here. It should solve backtesting issues with Renko.


Yo aslan you get cracking on those renko's don't you!! But why so many?

I am picking my way through Renko's in matlab... they are already included in the financial toolbox but not really in the way I want to use them. And anyway, the edge is in the numbers, not in the graphs!!

I like to start from scratch



CPI

Reply With Quote
 
(login for full post details)
  #26 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 since Aug 2009


aslan View Post
I created a new bar type called BetterRenko, and there is a new thread for it here. It should solve backtesting issues with Renko.

I don't know about solving, but every strat I tested that was glowingly profitable with Renkos is now a net loser with this. Can't say I'm the least bit surprised.

Reply With Quote
 
(login for full post details)
  #27 (permalink)
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
 
aslan's Avatar
 
Posts: 622 since Jan 2010
Thanks: 351 given, 1,116 received


Zoethecus View Post
I don't know about solving, but every strat I tested that was glowingly profitable with Renkos is now a net loser with this. Can't say I'm the least bit surprised.

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.

Reply With Quote
 
(login for full post details)
  #28 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


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.

Yo!

Say fella's, you are all pretty pessimistic when it comes to Renko, huh!

Reply With Quote
 
(login for full post details)
  #29 (permalink)
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
 
aslan's Avatar
 
Posts: 622 since Jan 2010
Thanks: 351 given, 1,116 received


cpi65 View Post
Say fella's, you are all pretty pessimistic when it comes to Renko, huh!

Not at all. I love Renko's for what they are good at, which is removing noise and showing real swings. They are horrible for backtesting if you are not real careful, and I was really trying to fix that issue so they could be used for that as well.

Reply With Quote
 
(login for full post details)
  #30 (permalink)
 cpi65 
UK
 
Experience: None
Platform: -
 
Posts: 155 since Aug 2010
Thanks: 12 given, 75 received


aslan View Post
Not at all. I love Renko's for what they are good at, which is removing noise and showing real swings. They are horrible for backtesting if you are not real careful, and I was really trying to fix that issue so they could be used for that as well.

Yeah, I know the renko's you get in most charts are dodgy for backtesting, thats why I'm building my own (in matlab)

Good luck bro! I'll see you on the other side!

Race ya!

CPI

Reply With Quote
 
(login for full post details)
  #31 (permalink)
 Zoethecus 
United States of America
 
Experience: Advanced
Platform: NT
 
Posts: 1,149 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.

Reply With Quote
 
(login for full post details)
  #32 (permalink)
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
 
aslan's Avatar
 
Posts: 622 since Jan 2010
Thanks: 351 given, 1,116 received


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.

Reply With Quote
The following 6 users say Thank You to aslan for this post:
 
(login for full post details)
  #33 (permalink)
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
 
gregid's Avatar
 
Posts: 651 since Aug 2009
Thanks: 320 given, 620 received

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 Reply With Quote
 
(login for full post details)
  #34 (permalink)
 Seberbach 
Midland, Michigan USA
 
Experience: Advanced
Platform: TradeStation, Biocomp
Trading: TF
 
Posts: 21 since Aug 2010
Thanks: 70 given, 22 received

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.

Reply With Quote
The following 2 users say Thank You to Seberbach for this post:
 
(login for full post details)
  #35 (permalink)
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
 
aslan's Avatar
 
Posts: 622 since Jan 2010
Thanks: 351 given, 1,116 received


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.

Reply With Quote
The following user says Thank You to aslan for this post:
 
(login for full post details)
  #36 (permalink)
 RJay 
Hartford, CT. USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: AMP/CQG, Kinetick
Trading: RTY
 
RJay's Avatar
 
Posts: 688 since Jun 2009
Thanks: 748 given, 781 received


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

Reply With Quote
 
(login for full post details)
  #37 (permalink)
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
 
aslan's Avatar
 
Posts: 622 since Jan 2010
Thanks: 351 given, 1,116 received


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.

Reply With Quote
The following user says Thank You to aslan for this post:
 
(login for full post details)
  #38 (permalink)
 Seberbach 
Midland, Michigan USA
 
Experience: Advanced
Platform: TradeStation, Biocomp
Trading: TF
 
Posts: 21 since Aug 2010
Thanks: 70 given, 22 received


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!

Reply With Quote
The following user says Thank You to Seberbach for this post:
 
(login for full post details)
  #39 (permalink)
 jlwade123   is a Vendor
 
 
Posts: 929 since Oct 2012
Thanks: 678 given, 897 received


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 Reply With Quote
 
(login for full post details)
  #40 (permalink)
 jlwade123   is a Vendor
 
 
Posts: 929 since Oct 2012
Thanks: 678 given, 897 received


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 Reply With Quote
 
(login for full post details)
  #41 (permalink)
 traderlange 
NY NY
 
Experience: Advanced
Platform: NinjaTrader
Broker: Amp/CQG
Trading: Futures - CL/GC/YM
 
Posts: 42 since Aug 2011
Thanks: 31 given, 209 received

I use Renko bars religiously in all my strategies, and here is what I've found works for me after many many horrid automated trading experiences. Account killers and 10's of thousands of dollars of losses. But Keep reading, I do this for a living now.....

1. Write your strat - (I like the idea of limits orders mentioned above)

2. Back-test. (2 or 3) tick slippage so you don't get too excited.

3. Genetic Optimization

now here is where it really gets important -----

4. Learn how to properly do walk forward optimization. I cannot stress this enough. And not just once - learn your strategies' ratio of Optimization Period and Test Period. Especially with a strat involving a lot of parameters. And limit dynamic params as much as possible. Know what your indicators are doing as only optimize the absolutely necessary prams. This is the only chance you'll get an out of sample test without a live market.

5. If you are still happy - you MUST do Monte Carlo simulations. This is the most under utilized tool and prob the most important thing NT has for testing. You WANT your strategies to run in noisy unexpected markets and fail. Read everything you can about how this works behind the scenes so you do it properly. And ALWAYS remove at least 5-10% of your best and worse trades. If that probability curve if out of whack, go back to the drawing board.

6. If things still check out - download a couple years of market replay and let er rip all night. This is the closest thing you'll get to building the bars likea live feed does (it's not, but close).

7. Then test in realtime - as this is really the only way to make sure your logic is solid (other than with actual $$)

8. repeat #4-5 every Sunday in volatile markets if you have too. Especially if you're trading craziness like the GC.

Look, I may be completely wrong..lol. But the workflow above works for me financially (after losing for eh, 8 years now, I'm finally in the black). Again, 4 and 5 - are an absolute must.

Also, if you're new at this, learn that your risk management & exit strategy code is more important that your entry signal. And don't always use trails --- think bigger. Especially with Renkos. The options are endless, Depending on market conditions i utilize 6 exit strats (beyond a set tick or $$ profit take)

1. EMA Trail
2. Fat Tails awesome super trend trail.
3. I have a custom MA that adapts to fake reversals - and exit when the slope changes <- this is my prize winner
4. Fast markets i use the slope change of this beauty anaZeroLagHATEMA again thank you @Fat Tails
5. For longer holds i'll use the trend change of my Adaptive Laguerre filter <- this rocks.
6. and sometimes anaADXVMA. and again @Fat Tails you rock.

(I'm actually almost finished with a chart trader add on that utilizes these seamlessly - i'll post when finished but it's a ton of code and I'm finally testing on the live markets)

Of course, proper entries are important, but if you're not netting a 3+ profit factor, you'll eventually blow your account. I've done it too many times.

There is my 2 cents for the for the eve - time to grab a beer.

Mike

Visit my futures io Trade Journal Reply With Quote
The following 7 users say Thank You to traderlange for this post:
 
(login for full post details)
  #42 (permalink)
 aaadetos 
houston, tx/usa
 
Experience: Intermediate
Platform: ninjatrader
Trading: es
 
Posts: 1 since Mar 2014
Thanks: 2 given, 0 received


gregid View Post
All renko incarnations (NT Renko, MedianRenko, SBSRenko, WickedRenko) are unreliable for backtesting due to few issues. One of these issues is redrawing the "open" of the bar after the bar has formed.

In order to avoid the complications of the redraw:

Tip

Refrain from using Market Orders for backtesting purposes and replace all MARKET orders with LIMIT orders with LimitPrice = Close[0]
(this will simulate standard behaviour of market orders for CalculateOnBarClose = true)



Sample code:

 
Code
                            
//instead of using:

EnterLong("entry1");
//use:
EnterLongLimit(Close[0],"entry1");
 
 
//instead of using:
EnterShort("entry1");
//use:
EnterShortLimit(Close[0],"entry1"); 
Good luck backtesting!

I have found that submitting market orders, via EnterLong() or EnterShort() in backtesting yields a different result than EnterLongLimit(Close[0]),"Buy") on the same backtest. When the exit strategy is to exit on conditions on the Renko chart, these appear to be ignored; and the entry and exit appears on the same Renko bar. Using EnterLong(), however, these enter on the new bar, as highlighted by others in this thread, and the rules appear to be followed.

What is a work-around for this in live testing? Live testing with the EnterLong()- ExitLong() sees eventual order rejections due to market movements within the Renko bar (Buy stops below the market/ sell stops above the market)...How could one then submit market orders on Renko charts in live testing without this occurring? Otherwise, how could one submit limit orders in strategy testing without also exiting on the same entry Renko bar?


Reply With Quote
 
(login for full post details)
  #43 (permalink)
 gregid 
Wrocław, Poland
 
Experience: Intermediate
Platform: NinjaTrader, Racket
Trading: Ockham's razor
 
gregid's Avatar
 
Posts: 651 since Aug 2009
Thanks: 320 given, 620 received


aaadetos View Post
I have found that submitting market orders, via EnterLong() or EnterShort() in backtesting yields a different result than EnterLongLimit(Close[0]),"Buy") on the same backtest. When the exit strategy is to exit on conditions on the Renko chart, these appear to be ignored; and the entry and exit appears on the same Renko bar. Using EnterLong(), however, these enter on the new bar, as highlighted by others in this thread, and the rules appear to be followed.

What is a work-around for this in live testing? Live testing with the EnterLong()- ExitLong() sees eventual order rejections due to market movements within the Renko bar (Buy stops below the market/ sell stops above the market)...How could one then submit market orders on Renko charts in live testing without this occurring? Otherwise, how could one submit limit orders in strategy testing without also exiting on the same entry Renko bar?


Quite a lot has changed since my original post - there have been many new renko implementations with real open and close - search for Beter Renko on this board.

Started this thread Reply With Quote
The following user says Thank You to gregid for this post:
 
(login for full post details)
  #44 (permalink)
Zananas
Paris France
 
 
Posts: 7 since Sep 2018
Thanks: 4 given, 1 received

Hi everyone,

First of all, thanks for all your tips and sharing your experience here.

I'm actually backtesting a strategy on GBPUSD using a Renko based charts.
Unfortunately I'm having some issue concerning exact opening/closing price position.

For exemple my long strategy is simply based on a direction change between two following Renko bars, here's my script
if (Open[0] < Close[0])
&& (Open[1] > Close[1])
{
EnterLong(Convert.ToInt32(DefaultQuantity), @"Long");
}

Here's a snapshot for illustration in attachment.
On renko #1 we notice a open > close, and on renko #2 a open < close, so my entry condition is triggered as soon as renko #2 is closed.
The issue remain here : opening position price is the open of renko #3 (red triangle) instead of closing of renko #2 (green triangle).
Hence my strategy tester remain on false price entry.

NB : obviously this issue ain't encountered on candlestick chart, as close from previous bar equals open of following. But renko chart are constructed totally different.

How NinjaTrader could to manage this error ?
Is there some code to implement in the strategy script to solve it ?

Thanks a lot for your help

Attached Thumbnails
Click image for larger version

Name:	GBPUSD (140 Renko)_cropped.png
Views:	59
Size:	2.8 KB
ID:	255110  
Reply With Quote
 
(login for full post details)
  #45 (permalink)
 rleplae 
Gits (Hooglede) Belgium
 
Experience: Master
Platform: NinjaTrader, Proprietary,
Broker: Ninjabrokerage/IQfeed + Synthetic datafeed
Trading: 6A, 6B, 6C, 6E, 6J, 6S, ES, NQ, YM, AEX, CL, NG, ZB, ZN, ZC, ZS, GC
 
rleplae's Avatar
 
Posts: 2,991 since Sep 2013
Thanks: 2,437 given, 5,802 received

It all depends how you back test.

Live testing is not equal to replay
replay is not equal to fast forward

I will post some more evidence,
and I am sure that some folks will completely freak out on the findings

If you replay the data at real-time speed, you get what is supposed to be near real live results
(who has that patience ?)

If you fast forward replay the data, you get very different results..
result that will not be in relation to what you can expect in a real market

When you ask a computer to calculate something
and you ask the computer to do it slowly
or you ask the computer to do it fast
you expect the results to be the same

If you do something in Ninjatrader,
that logic does not work..
slow is not equal to fast
and i'm not talking about the comm's delay
you can put the delay to 0

Even worse
if you have more than 500 historical trades
this issue even gets worse
a lot worse..

stay tuned, i'll post some findings in the next days
it will show that a live working strategy,
in back testing completely fails
and vice-versa

if you are a gold digger
still trying to find a holy grail ?
you should be aware of these things
if not, it will sting you badly..

Follow me on Twitter Visit my futures io Trade Journal Reply With Quote


futures io Trading Community Platforms and Indicators NinjaTrader > Tip for backtesting on Renko charts


Last Updated on March 8, 2019


Upcoming Webinars and Events

NinjaTrader Indicator Challenge!

Ongoing

Journal Challenge w/$1,800 in prizes!

May 7

The Cold Hard Truth: Maybe I Am Not Good Enough w/Chris Gray @ Earn2Trade

Elite only
     



Copyright © 2021 by futures io, s.a., Av Ricardo J. Alfaro, Century Tower, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada), info@futures.io
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.
no new posts