Question about using the "Jump" and "Speed" setting in Tick Replay?

[demarcog]

Does using a SPEED setting of other then 1 and JUMP to some time period ahead of the current bar, still result in each tick being processed sequentially by the efs or is processing different depending on these settings?


I'm having alot of difficulty trying to validate the results of a back tested strategy by comparing the trades reported in a back test with the generic broker trades generated by tick replay.

Wanted to make sure that using these settings didn't effect the logic flow of my strategy?

Thanks,

Glen

[eSignal_JasonK]

Re: Question about using the "Jump" and "Speed" setting in Tick Replay?

Hello Glen,

Originally posted by demarcog
Does using a SPEED setting of other then 1 and JUMP to some time period ahead of the current bar, still result in each tick being processed sequentially by the efs or is processing different depending on these settings?

Each tick gets processed by the EFS regardless of the speed or jump settings. The only exception is if you're using setComputeOnClose(), then the EFS processes once per bar interval.

I'm having alot of difficulty trying to validate the results of a back tested strategy by comparing the trades reported in a back test with the generic broker trades generated by tick replay.

Wanted to make sure that using these settings didn't effect the logic flow of my strategy?

Thanks,

Glen

Back tested trade prices that are evaluated on a completed bar basis cannot be expected to match exactly the tick-by-tick evaluations where trades are allowed to be triggered intra-bar. Certain assumptions can be made on historical completed bar analysis, but should be expected to be slightly different than real time or tick-by-tick analysis. For example, on any given historical completed bar while back testing, the EFS evaluates the bar only one time. EFS does not know if the high for that bar occurred before or after the low of that bar. The high may have triggered a profit target and the low may also have triggered a stop. Which one occurred first? Some assumption has to be made here. Choose the assumption that is more conservative. To produce the most conservative result in back testing formulas, check for the stops triggers before any profit targets. The back test for our example here would record the stop and a loss for the position assuming a fixed stop was used. However, the tick-by-tick evaluation of this same bar may have traded up to the high first and triggered the profit target. A much different result than the back tested results, but hopefully this illustrates why you may be seeing differences between back tested trades and tick-by-tick trades.

For more related details, you may also want to review my reply to you in a previous discussion we had on a similar topic. The same general concepts may apply here as well.

[demarcog]

Re: Re: Question about using the "Jump" and "Speed" setting in Tick Replay?

Originally posted by JasonK
Hello Glen,



Each tick gets processed by the EFS regardless of the speed or jump settings. The only exception is if you're using setComputeOnClose(), then the EFS processes once per bar interval.



Back tested trade prices that are evaluated on a completed bar basis cannot be expected to match exactly the tick-by-tick evaluations where trades are allowed to be triggered intra-bar. Certain assumptions can be made on historical completed bar analysis, but should be expected to be slightly different than real time or tick-by-tick analysis. For example, on any given historical completed bar while back testing, the EFS evaluates the bar only one time. EFS does not know if the high for that bar occurred before or after the low of that bar. The high may have triggered a profit target and the low may also have triggered a stop. Which one occurred first? Some assumption has to be made here. Choose the assumption that is more conservative. To produce the most conservative result in back testing formulas, check for the stops triggers before any profit targets. The back test for our example here would record the stop and a loss for the position assuming a fixed stop was used. However, the tick-by-tick evaluation of this same bar may have traded up to the high first and triggered the profit target. A much different result than the back tested results, but hopefully this illustrates why you may be seeing differences between back tested trades and tick-by-tick trades.

For more related details, you may also want to review my reply to you in a previous discussion we had on a similar topic. The same general concepts may apply here as well.

Jason,


Thanks very much for the reply. I now understand how the results can vary between back testing and real time.

One issue I didn't realize when I initially posted and was confusing the issue of matching back tested and real time trades was the sequence of trades listed in eSignal Paper Broker Execution window is can be listed out of sequence from the actual chronological order in which they were executed.


The orderid properly reflects the chronological trade history and not the sequence in which the trades are listed in the executions report. I mention this as a heads up to others because at first I thought I had a logic error.

The other issue is that when I use the JUMP key to move forward I also get different results. I put a debug statement at each NEWBAR and increment a vMyBarCnt++ for each occurance of NEWBAR and when I debugprint getCurrentBarCount() & vMyBarCnt they are identical until I use the jump key. Then vMyBarCnt values are much higher then getCurrentBarCount().

How my efs can be processing bars and incrementing a counter at newbar and not at the same time having getCurrentBarCount() increment is a bit of a mystery to me and might also be an issue with the replayed results?


I very much appreciate your assistance and patience helping me and others understand these subtle but critically important complexities.

Glen

[eSignal_JasonK]

Re: Re: Re: Question about using the "Jump" and "Speed" setting in Tick Replay?

Hello Glen,

Originally posted by demarcog
...

The other issue is that when I use the JUMP key to move forward I also get different results. I put a debug statement at each NEWBAR and increment a vMyBarCnt++ for each occurance of NEWBAR and when I debugprint getCurrentBarCount() & vMyBarCnt they are identical until I use the jump key. Then vMyBarCnt values are much higher then getCurrentBarCount().

How my efs can be processing bars and incrementing a counter at newbar and not at the same time having getCurrentBarCount() increment is a bit of a mystery to me and might also be an issue with the replayed results?

Clicking the Jump button triggers a reload of the EFS, which does not reinitialize global variables. You need to reset your vMyBarCnt variable to 1 at BARSTATE_ALLBARS so that it gets reinitialized properly when you click the Jump button.

I very much appreciate your assistance and patience helping me and others understand these subtle but critically important complexities.

Glen

You're most welcome. Thank you for your comments.

[demarcog]

Re: Re: Re: Re: Question about using the "Jump" and "Speed" setting in Tick Repl

Originally posted by JasonK
Hello Glen,



Clicking the Jump button triggers a reload of the EFS, which does not reinitialize global variables. You need to reset your vMyBarCnt variable to 1 at BARSTATE_ALLBARS so that it gets reinitialized properly when you click the Jump button.





You're most welcome. Thank you for your comments.

Jason,

I didn't realize that "JUMP" option caused a realod of the EFS.

I appreciate you making me aware of that and the suggestion for dealing with the situation, it did correct the erroneous counter information I experienced.

While searching the forum, I did run across this old post:

http://forum.esignalcentral.com/showthread.php?s=&threadid=4669&highlight=tick+replay+jump

For some strange reason my results are also different when the JUMP key is used, not a major issue however.

I do like the suggestion made of increasing the SPEED as it can take awhile even at 200 ticks bursts to cycle through 10 days worth of data.

Thanks very much for the information, it does explain alot and the suggestion for reinitializing a global variable using _ALLBARS.

Glen