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!

Viewing 15 posts - 1 through 15 (of 46 total)
  • #193942

    BT-1

    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 …

    1. When we click a line in optimisation results, the results we see ARE under ‘Tick by Tick’ conditions.
    2. 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.
    #193945

    That’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?

    #193947

    Is 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!!?? 🙁

    #193951

    @Nicolas

    I think we urgently need an explanation from the expert.

    #193952

    Ummm, WHAT? *insert brain exploding*

    I think that could explain a few oddities.

    #193953

    This 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???

    #193958

    I 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.

    #193960

    No real proof, and screenshots of it I can’t find (I probably have too many screenshots 🙂 ), but this should speak.

    #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!!!??? 🙁

    #193964

    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.

    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.

     

     

    #193966

    I 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?? 🙁

    #193970

    If there is always a “0” in the “Tick mode” column in the optimization report, that’s good, isn’t it?

    #193971

    2 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.
    #193972

    The link to the French forum topic.

     

    https://www.prorealcode.com/topic/backtest-mode-tick-par-tick/

     

     

    1 user thanked author for this post.
    #193973

    that’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.
Viewing 15 posts - 1 through 15 (of 46 total)
Similar topics:

Create your free account now and post your request to benefit from the help of the community
Register or Login