For some time I have struggled to get the indicator results to be indentical between historical processing and real-time processing.
One of the struggles I am running into is data alignment between the primary tick bar (1000 ticks) and the intra ticks. Upon debugging, I ran into a oddity that I cannot explain.
Upon printing the data on each tick, I noticed a couple issues.
The primary bars index is initialized to -1 for the beginning of the historical data loaded. Not sure what the issue is with that, but that doesnt seem reasonable. The real issue is that, the primary bar's index becomes 0 on tick 983, and not tick 999 or 1000. The primary bar index does correct itself when it increments to 1, on tick 1999 (making 1998 final tick. Primary bar index moves to 2 on 2997. Technically this is an off by one error, as that puts 998 (0 index based) index counts between the primary bar being incremented. This behavior is seen in both historical and realtime processing.
The secondary (1 Tick) bar series is initialized to 1 on the first tick, which makes this alignment issue even more odd.
My hope is that there is some thing I am missing that is causing this issue. Now, I do not believe I need to use TickReplay. I am using 1 Tick bars to perform the data aggregation and analysis, but with tick bars, there is a path dependence that has be respected in order for any historical data testing to even be able to be compared to realtime analysis. In order to perform validation and verification of analysis results, I have to be able to get historical results to match realtime results, and while I can get very close, a tick being miscounted under a different bar can accumulate error and change the outcome of the analytical tool.
Please advise NT team!
Comment