Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
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 for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Thanks for chiming in Anthony, now we can deal in facts instead of just opinions.
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).
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).
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.
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.
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.
In truth I never had an issue with the opening bar ticks fill, so I never thought in that level of detail. I will investigate this, thank you.
You are correct, the consistent reference is only an issue when the time stamp doesn't come from the data provider, but is created based on the computers clock. MBTrading (to name one) with NT uses the computers clock for time stamps, which explains why I have seen this issue.
I have tested the dynamic brick size algorithm for consistency during backtesting and it is consistent. As long as the first day of backtesting has 1 day of historical tick data loaded, the underlying data stream is the same and so is the calculation.
I appreciate the level of scrutiny and detail you have given to my white paper. Thank you again for taking the time to review it.
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?