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 - 16 through 30 (of 46 total)
1 2 3 4
  • 05/27/2022 at 12:00 PM #193974
    PeterSt
    GraHal wrote:

    I feel like loads of my > 6000 Algos stored on my PC now contain lies!!!??? 🙁

    Not yet …
    😉

    GraHal wrote:

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

    FY(hopefully reliable)I :

    There’s a lot of hoopla around on the tick by tick stuff and although we may learn from what e.g. support tells us, or even what a broker may come up with (or what we ourselves spout). I say : this is not even related to several orders in one bar (although results without tick by tick will be severely false for such situations). What it is related to is the necessity (read : requirement) of each in-candle happening to be covered for which can only go (for the Backtesting Engine analysis) via Tick by Tick. And this includes a Target Profit. It includes everything which can happen in candle for Enter, Exit, Trailing (leading to Entry or Exit).

    05/27/2022 at 12:00 PM #193975
    phoentzs

    Ok, you were faster.

    05/27/2022 at 12:09 PM #193976
    PeterSt

    Thank you guys.
    Well, the context is at least that this is only from 3 days ago (May 24). The OP of that topic says he pulled a technical report for PRT.

    @GraHal, you may remember that I called our support with similar, about 3 months ago. This originally was in the context “something has changed”. But I got debunked because my support guy could 100% explain to me what I could not see myself. Still something had changed, to my belief. Say 3 months back.

    05/27/2022 at 12:20 PM #193977
    PeterSt

    Then another FYI:

    What’s being told there (literally by Nicolas) is that the backtest results (from the list you’re presented) don’t take into account the relative results of Tick by Tick.
    Now me :
    Notice what’s on the bottom line of that result list : “Click for Tick by Tick results”. And that is exactly what happens. Thus :

    This is about my in several occasions mentioned “the result of the Statistics form are different than what the Optimisation Result (top line) shows. Thus what happens ?

    After the result list has been built PRT (usually) auto-selects the first line and this acts as whether you clicked it (again see bottom line message).
    To me this means that the result of the result line you selected, is OK in the Stats form.

    And you may recall my kind of advice about this all : If the result in the Stats form is too much off from what you see in the list, you inherently do something not-so-right. And backtesting with the checkbox active *and* clicking the right buttons, is always better than e.g. not checking the checkbox.

    You will also remember the rightmost column in the Optimisation Result, which best shows 0 (column named Tick Mode (-secret)).

    My Live still shows the very same as Forward Backtest, with the additional notice that my Backtest always has all the Optimisation Parameters still there, in various status I told about earlier in the topic.
    The only thing a (forward) Backtest can not resemble, is the exact time of the entries/exits. This is because the Backtest only works at the TF of the chart … But the price is sufficiently close to 100%.

     

     

    05/27/2022 at 12:54 PM #193982
    PeterSt

    Try to wrap your head around this :

    https://www.prorealcode.com/topic/something-fundamentally-wrong-with-optimisation-variables/

    Chances are fair that such a thing is the issue here too. Or let me put that differently :
    If we move our Optimisation Variables to the program code, we d*mn well know how to declare it there. PRT does not know it, and makes them declared ONCE.
    I always move them and have no issue with the subject of this topic (as how it looks). If I would move them wrongly (make them declared without ONCE) I will always do it differently than what the Optimisation (backtesting) depicts. So if my optimsation is satisfactory, but Demo or Live fails on me, it is because the Demo/Live is the wrong one (I supposedly should have injected the variable myself without the Once keyword).

    If you could really wrap your head around the topic I linked to, you can see it is more complicated and I would not be able to decide what the difference in results should be. This is because PRT is definitely doing it wrong, when I start to add to an Optimisation Variable which it chokes on (of what I recall the base for the addition is the largest negative number possible).

     

     

     

    05/27/2022 at 1:00 PM #193983
    GraHal
    PeterSt wrote:

    What’s being told there (literally by Nicolas) is that the backtest results (from the list you’re presented) don’t take into account the relative results of Tick by Tick.

    We have always understood above about results shown in the optimisation Table, but above is not how I read what Nicolas  stated.

    Nicolas stated …
    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.

    This Topic is about us not getting Tick by Tick results when we backtest using fixed values in the optimiser (with Tick by Tick enabled … as Nicolas states above.

    05/27/2022 at 1:09 PM #193984
    GraHal
    PeterSt wrote:

    PRT does not know it, and makes them declared ONCE.

    So are you saying the ONCE values placed at the top of Auto-Systems (automatically by PRT) are amiss in some way and are a PRT ‘second-best attempt’ at getting variable values into the code??

    05/27/2022 at 1:42 PM #193988
    PeterSt
    GraHal wrote:

    So are you saying the ONCE values placed at the top of Auto-Systems (automatically by PRT) are amiss in some way and are a PRT ‘second-best attempt’ at getting variable values into the code??

    Yes, sort of. My point on the subject would be that during Backtesting similar has to happen and at least that provenly fails (depending on how you deal with all in the code yourself, like letting reference a variable to itself (A = A + 1). Mind you, I can not prove how an Optimisation Parameter is obtained in the code during Backtesting so we can only assume it is similar to making a code ready for Live. The only thing I can say kind of definitely is that the preparation for Live can do quirky things as putting the Once declarations in from of DefParam commands, and then all fails right away – and this does not fail at all during backtesting/optimisation – so … N.b.: I said can do because this issue is solved, but it testifies of both situations not being 100% equal.

    The other answer is : The user (we) should know how to deal with it. And like I said in that linked topic : nobody will be able to except for the hand full.
    But you also saw me only last March obtaining those variables with a decimal because PRT itself does that too (when the Optimisation Variables are sustained and given to Live). This too is to get Live equal to Backtesting. But prior to March (2022) I didn’t know that one yet. And there’s probably much more I don’t know.

    05/27/2022 at 1:50 PM #193989
    PeterSt
    GraHal wrote:

    We have always understood above about results shown in the optimisation Table, but above is not how I read what Nicolas  stated. Nicolas stated … 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. This Topic is about us not getting Tick by Tick results when we backtest using fixed values in the optimiser (with Tick by Tick enabled … as Nicolas states above.

    Yes, I know. But this is not how I interpret things and this is exactly why I wanted the context of that phrase/quote. I read the whole topic …

    Nicolas determined in ad-hoc fashion what could be going on and how to solve it. It was not a ready answer. Also a good reason not to spread the word right away.
    And I think he could judge wrongly.

    This is not about him against me or something, but I don’t have the issues and use it all heavily. I also have my context, and you just read some of it. I suppose if @Nicolas is around to respond, he will do so. This can include “I don’t know yet”.

    If possible, try t re-read my post about the clicking on the lines of the Optimisation Result list. I don’t say they are correct. I only say that when you click them or when PRT shows the Statistics form, that *then* the results on that form show fine, *IF* you ticked the box Tick by Tick mode and *IF* you pressed the right button.
    Nothing about that all in that French topic. Something not being dealt with is context just the same, right ?

    05/27/2022 at 1:54 PM #193992
    GraHal
    PeterSt wrote:

    The only thing I can say kind of definitely is that the preparation for Live can do quirky things as putting the Once declarations in from of DefParam commands, and then all fails right away

    I’m assuming a typo with … in from of … DefParam (you meant to type in front of).

    PRT never does put the Once values (values taken from the fixed values in the optimiser) in front of DefParam commands … PRT places the ONCE values after DefParam commands.

    PeterSt wrote:

    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.

    I think you are doing something weird to get rejection due to the ONCE values. They work seemlessly for me > 99% every time.

    I have occasionally seen the message that you hint at … “replace values from optimser into the strategy code” or similar? I also must – at that < 1% occasion – have been doing the same weird thing you do repeatedly?

    05/27/2022 at 2:20 PM #193994
    PeterSt
    GraHal wrote:

    I have occasionally seen the message that you hint at … “replace values from optimser into the strategy code” or similar? I also must – at that < 1% occasion – have been doing the same weird thing you do repeatedly?

    Yeh, but I don’t know which it is and never take the time to sort it out. THUS I always lose time with obtaining the lot in the code.

     

     

    GraHal wrote:

    I’m assuming a typo with … in from of … DefParam (you meant to type in front of).

    Yep.

     

     

    GraHal wrote:

    PRT never does put the Once values (values taken from the fixed values in the optimiser) in front of DefParam commands … PRT places the ONCE values after DefParam commands.

    As I said, this is solved now. But in some stage it really didn’t do that part right.

    PS: Don’t think I ever struggle, OK ? see text below.
    😉

    05/27/2022 at 3:06 PM #193998
    Nicolas

    ok guys, to summarize a bit what happened in that french topic:

    1. optimization has NEVER EVER used tick by tick checking (intrabar check for price touching stoploss or takeprofit before or after in the same bar, used to be named the “0 bar issue”), even if the checkbox is ticked
    2. if values are present in the optimization window and are “fixed values”, the backtester consider the basktest as an optimization and so fallback in the same situation as in 1/

    I must admit it surprises me a bit (point 2.), would you mind waiting for Monday so I can get a more precise explanation for that point please? 🙂

    1 user thanked author for this post.
    avatar GraHal
    05/27/2022 at 3:22 PM #193999
    PeterSt
    Thank you, Nicolas.
    Nicolas wrote:

    optimization has NEVER EVER used tick by tick checking (intrabar check for price touching stoploss or takeprofit before or after in the same bar

    Translated by me :
    Optimization is : finding the best combination out of all possibilities, usually sorted on Gain. Because the Tick by Tick is not respected as you said, the combination showing as the best, may not be the best and another combination is (read : the sequence can be mixed up somewhat).

    However

    Once a result line is clicked, the tick by tick is respected and the real gain (and equity curve and all) show in the Statistics form.

    If this is correct in your view, then nothing changed and at least I knew. But where this all is spelled out, is something else.

    What would be new to me is that the cause of this all is the fixed variables. And what it implies is that when a fixed variable is set to e.g. 25, letting that variable range from 25 to 25 would yield a different result ? … I doubt that.
    I can only hint once more at putting Optimisation Variables to code from the Optimization form can yield a difference. But this is unrelated to the Tick by Tick (or it is, but then there’s an additional dimension at play).

    Of course we can wait till Monday. But it intrigues. 🙂

     

     

    05/27/2022 at 3:40 PM #194002
    Nicolas
    PeterSt wrote:

    Once a result line is clicked, the tick by tick is respected and the real gain (and equity curve and all) show in the Statistics form.

    Yes that’s right. Backtest is using the tick by tick mode (if checked) when you click on the line of the optimization results.

    05/27/2022 at 4:49 PM #194009
    phoentzs

    And would it be ok to leave the fixed values ​​in the optimizer and set the strategy live like this? Or is it better to write the values ​​in the code?

  • Author
    Posts
Viewing 15 posts - 16 through 30 (of 46 total)
1 2 3 4

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
tick by tick vs. timeframe

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