* Open Price - My comment about the open = prior bar close is referring to when a reversal bar is created. Typically in traditional renko charts when an opposite direction bar is created the Open of the new bar is set to the open of the prior bar. This is what confuses NT during backtesting, and gives spurious results. Yes, the opening tick doesn't have to be at the exact price of the close of the prior bar. What I am talking about is the traditional method a Renko bar is constructed, not the true tick price. The backtesting ability of the bar provides an identical result to the BetterRenko, where reversal bars Open is set to the close of the prior bar. I don't understand why you think it could be a backtesting issue; the bars are plotted in the same manner as yours.

* Tick Filtering -- Agreed. It should be left up to the platform to control tick filtering, assuming the platform employs a logically sound algorithm for tick filtering. The problem with NTs tick filtering method is that it checked the percent difference of the current tick from the prior tick, but does not discard the tick in the algorithm if its discarded from the chart; It uses it in the next filtering computation. If the next tick is also an out-lier based on the first out-lier, it is considered okay and is used. So if you have more than 1 bad tick, which is the case sometimes with MBTrading, the Renko chart can form many bars and become useless for a time span.

* Consistent reference point - The issue with using a session time for the consistent reference point is that computer clocks are likely different between computers. You can have two systems in the same room collecting from the same data stream and if their clocks are off a few seconds the new session tick price can be different. This can lead to different results between computers. I found this to be problematic when using one computer for optimizing a trading system, then trading with a different because the results would be inconsistent.

* Dynamic Brick Size -- I don't fully understand why you feel this could be a real problem in backtesting. The bricksize chosen at the beginning of the day is consistent based on the prior days tick data. As long as the same bricksize is chosen by my algorithm for a specific day, which it is, the bricksize is consistent and backtesting will be consistent as well. No matter which method is used, as long as its consistent, its is sound backtesting.

* Handling Gaps -- Dummy bars are inserted. I thought about how this should be done for a while and thought it was best to preserve the computations of an indicator. Some indicators will drastically overshoot / become disrupted if a gap is present.

I enjoyed the movie and I use LogicRenko bricks. I can trust the tick data live and in Memorex.

An excellent replacement for range and other Renko type, too. Performs particularly well on automated breakout strategies. Highly recommended.

Hey Lars,

Have you compared Logik Renko vs. Better Renko? If so, how do you see the differences?

Thanks, Jeff

LogicRenko is more feature rich than BetterRenko.

I did a one week free trial of the Logik Renko and many of the "features" were not advantageous to live trading.......it seems to me that the features might be more advantageous to ATS and backtesting results. Am I right? Or have I jumped to an incorrect conclusion?

Isn't ATS live trading? Do you mean discretionary trading?

If you set the six digit Logik Renko to 2009111 it is the same as setting the Better Renko to 9 assuming the same start time.