Backtest NOT ‘Tick by Tick Mode’ even if Box is Ticked!
Forums › ProRealTime English forum › ProRealTime platform support › Backtest NOT ‘Tick by Tick Mode’ even if Box is Ticked!
- This topic has 45 replies, 6 voices, and was last updated 2 years ago by drollo29.
-
-
05/27/2022 at 10:13 AM #193942
So did we all know this??
In optimization mode, the backtest does not use the tick-by-tick mode, even if the box is checked. You must define your variables directly in the code and delete those present in the optimization window.
Above is a statement from Nicolas on a French Forum. See attached for an example screenshot to illustrate above.
So …
- When we click a line in optimisation results, the results we see ARE under ‘Tick by Tick’ conditions.
- If we then enter those same values (from ‘Tick by Tick Mode’ at 1. above) into the optimiser (fixed value field) the results we see ARE NOT under ‘Tick by Tick’ conditions.
05/27/2022 at 10:33 AM #193945That’s exactly what I saw and I’m a bit confused. I often optimize one value at a time. So have values as fixed AND variable for optimization during optimization. When I’m done, I set the strategies live with fixed values in the optimizer. So never write the values directly into the code, they are always fixed in the optimizer. Is that good or bad now?
05/27/2022 at 10:57 AM #193947Is that good or bad now?
‘Now’ might be the operative word?? Have PRT changed something recently?
My OP describes a crazy way for PRT to set up the Platform to operate?
We all work similar to as you describe above phoentzs … we have to due to the slowness / ‘snail pace’ of PRT during optimisation!?
I store (ready for test – optimised Algo’s) on my PC and then pull them back onto the PRT Platform when I have space available for Demo Forward Test (FT). Since v11, I never enter any hard values in the code from the optimiser.
Seems our whole way of working has been blown away by this revelation???
What is worse … we have been labouring under an illusion that ‘Probacktest my System’ means what it says??
I can feel a 6 month break coming on!!?? 🙁
05/27/2022 at 11:03 AM #19395105/27/2022 at 11:07 AM #193952Ummm, WHAT? *insert brain exploding*
I think that could explain a few oddities.
05/27/2022 at 11:22 AM #193953This revelation means we can’t rely on backtest results using fixed values in the optimiser and this will therefore mean more overall optimisation by users in order to get Tick by Tick results??
Either above, else the nausea of entering fixed values in the code?? 🙁
But why did PRT come out with (in v11) that fantastically useful way of taking the fixed values from the optimiser and making them ONCE entries for Auto-Trading? It’s like somebody had a great idea (ONCE entries from fixed values) but the idea was not thought through everywhere … so fixed values in the optimiser give Tick by Tick results??
One thing for sure, my first paragraph above looks like it will result in even more load on PRT Servers???
05/27/2022 at 11:27 AM #193958I think we urgently need an explanation from the expert.
Haha, I think I urgently need to understand this.
First off, I always hard-code the variables into something which goes to Live or Demo(-Live). This is so because once I start the Strategy, it is rejected right away otherwise. No issue, but anyway it is so.
Next, I never saw a difference, I *do* use the in-bar stuff so I should be bothered with it when it goes wrong (GraHal, you know exactly what I mean), and I either work with ranges and next make a selected value fixed (never saw a difference) or I even work with ranges like “2.05 to 2.05” as a variant on fixed because I want to prserve the previous fixed value for a while. Again, no difference.
Lastly, I was this guy who claims that his forward testing shows 100% what Live or Demo-Live does. And I see no difference occurring (all entries and exists are synchronised).
This does not mean that what you see, GraHal, is not there. It only means that I need to understand when this exactly occurs (it is of crucial importance).
One thing I know : when you leave it to PRT to make the fixed Optimising Parameters into Once commands in the code, PRT defines them with a decimal. This won’t happen to me because I make the Once commands myself (because the Optimisation Parameters are eliminated, as told above). And in cases this makes a difference (which is buggy in itself). I have also seen declarations by PRT like 7.0000000001 while I declared it with 7 (didn’t count the zeroes but more than 5). This is not buggy but a bug for sure.
… But this is not directly related to Tick by Tick not being respected. And it is might difficult to prove that, right ? But that results become different of what I described, sure.And oh, the pointing at the various buttons to start a backtest (including the implicit one after PRT-start) is quite another subject. That’s one big bug all together and this only severely confuses the subject (but people should know, might they want to mimic behaviors).
Another thing I know for sure too : in that area of the Optimisation Parameters a LOT is going on and apparently it is difficult for PRT to get that right. Some times I can obtain only rubbish from backtests and then there’s nothing else for solution than create a new Strategy (no copy !) and type over the Optimisation Parameters. Last time this was needed was last week.
If there is something to really try, I like to help. But I suppose it will be a long-winded matter.
05/27/2022 at 11:42 AM #19396005/27/2022 at 11:43 AM #193962. It only means that I need to understand when this exactly occurs (it is of crucial importance).
We should notice this occurs if we have Stops and Targets that can both could potentially be met in the same bar.
My experience shows that a Strategy does not have to include BOTH hard stops like Set Stop pLoss and Set Target pProfit.
Reason I say above is I have been working on a Strategy recently that has ONLY Set Target pProfit (i.e. NO hard coded SL at all) but nonetheless gives different results with Tick by Tick enabled / ticked than with Tick by Tick disabled / unticked.
Clearly the optimiser is assessing Set Target pProfit against exit conditions at a Loss and deeming that both could potentially be met in the same bar??
I feel like loads of my > 6000 Algos stored on my PC now contain lies!!!??? 🙁
05/27/2022 at 11:48 AM #193964In optimization mode, the backtest does not use the tick-by-tick mode, even if the box is checked. You must define your variables directly in the code and delete those present in the optimization window. Above is a statement from Nicolas on a French Forum.
Link ?
1. Why is this only in the French forum ? (I know, Roberto will throw out double posts);
2. Why aren’t we informed in a very explicit way (assumed this is all said by Nicolas indeed);
3. Why isn’t it solved ?I asked for the Link to see whether there’s maybe important context.
05/27/2022 at 11:48 AM #193966I have instances of the 1.00000001 also in the ‘ONCE values’ . When I spot them I edit back to 1
There are so many oddities, bugs and Improvement Suggestions that if I / we documented them all to PRT, we would never have time to ‘try’ and make money?? 🙁
05/27/2022 at 11:55 AM #19397005/27/2022 at 11:56 AM #1939712 Links to more or less the same statement from Nicolas.
1st Link is the one I quote in my OP.
https://www.prorealcode.com/topic/backtest-mode-tick-par-tick/#post-193927
https://www.prorealcode.com/topic/backtest-et-verification-des-gains/#post-193931
1 user thanked author for this post.
05/27/2022 at 11:59 AM #193972The link to the French forum topic.
https://www.prorealcode.com/topic/backtest-mode-tick-par-tick/
1 user thanked author for this post.
05/27/2022 at 11:59 AM #193973that’s good, isn’t it?
Yes it is, and I understand why you ‘now’ doubt it … as we have had the ‘carpet pulled from under us today’ … we are starting to doubt everything? 🙁
1 user thanked author for this post.
-
AuthorPosts
Find exclusive trading pro-tools on