PureLogikTrading | Trading Reviews and Vendors


futures.io - futures trading strategies, market news, trading charts and platforms


Trading Reviews and Vendors


Discuss and review vendors of commercial trading products, trading rooms and services, trading indicators or third-party paid add-ons




 

PureLogikTrading

  #11 (permalink)

Elite Member
Madison, WI
 
Futures Experience: Advanced
Platform: Sierra Charts, ALT
Favorite Futures: ES
 
aslan's Avatar
 
Posts: 614 since Jan 2010
Thanks: 343 given, 1,092 received

Thanks for chiming in Anthony, now we can deal in facts instead of just opinions.


mrlogik View Post
* 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.

The plotting is not the issue, but it is the underlying data. When you backtest, the OHLC values are used (and the range of values the bar forms). Depending how you write the strat or set options, the first tick of the next bar could be your fill, so if you don't have the correct value you do not get real results (although it would backtest the same each time it does not match real trading).


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

I have never needed this, but others have shown me examples where it is pretty bad for certain instruments. I have never added to BR. As you are aware adding config options can be a hassle (your masking options are very clever).

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

Depends where the timestamp is coming from. If you are using exchange based timestamps, there is no issue, as they are not going to change even when you reload historical data. If you are using PC based timestamps, then I agree you have issues to deal with.

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

It is not an issue as long as the algorithm always gets the same answer based on the data stream. The real test is if I load day X of data with a start date of day (X-5) and then again with start date of day (X-0), I should get the same bars for day X. If you don't get the same data then your backtest may have issues. This issue is similar to the consistent reference point.

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

Yes, indicators can move faster, but I would rather have that then known bad data for a backtest. Once you insert those dummy bars, you now have data on the chart that the backtest will execute against. Obviously, this is an issue.

This is one of those issues that you have to trade off as a user. Is the backtest more important, or is the visual of the chart more important. No right answer, just depends what you are looking for. BR focuses on the backtest. Some like the visual cascade of the gap.

Reply With Quote
The following 4 users say Thank You to aslan for this post:
 
Page generated 2018-11-21 in 0.09 seconds with 11 queries on phoenix