Cumulate orders and decimal position size strange backtest results

Forums ProRealTime English forum ProOrder support Cumulate orders and decimal position size strange backtest results

Viewing 15 posts - 16 through 30 (of 39 total)
  • #57340

    I have sent a problem report to PRT as this issue is stopping me from trusting this strategy to run live with decimal position sizing.

    #57363

    Good ! Thank you. Let me know when they solved it. As I said, I have no problems with decimal position sizes in live trading, but in the backtest, this is very disturbing.

    When I replace the equivalent of

    PositionSize = Round(PositionSize*100)
    PositionSize = PositionSize/100
    in my backtest by
    PositionSize = Round(PositionSize)
    everything runs fine, otherwise it does not.
    #57366

    Yes whole numbers work fine but not decimals and I like decimal position sizing as it gives us much closer control over our risk size.

    #57395

    OK. Let’s take this simple system that reproduces the whole mess. It runs in the DAX min 1 minute chart, 1 EUR mini contract, :

    This system alternately buys and sells short a position every 20 bars. No position therefore lasts longer than for 20 bars.

    Now, let’s take the same system, but replace integer position sizes by position sizes with 2 decimals only by using n = round(number * 100) / 100 instead of n = round(number).

    It should yield exactly the same number of positions, lasting for 20 bars or less, but it DOES NOT.

    The backtest curves superficially look quite identical, but in detail, they are not at all. Test done for 10.000 bars.

    DAX-1-Minute

    Now, let’s compare the backtest reports :

    comparison-backtest-reports

    Both backtests should yield the same number of positions and the same time in the market. However, the system with decimal position sizes has more positions (625 instead of 526 for integer position sizes), and it seems to be much longer in the market, 92.51% instead of 69,87% for integer position sizes.

    Now we will see, why this is so :

    comparison-backtest-reports-2

    As in your system, Vonasi, the test system with decimal position sizes shows positions in the backtest report that do in fact not exist, and they last longer than they could in fact (longer than for 20 bars).

    Now let’s take the longest wrong position with decimal position sizes (40 bars on 28.12.2017, 15:02 to 28.12.2017, 15:42) and see what the chart shows during this time :

    chart-comparison-2

    Both systems show the same actual positions, the “wrong” position with 40 bars is not there, but instead we see once again these strange “spikes” around the time when the wrong position was reported for decimal position sizes.

    So, I conclude that this is a general and reproducible bug for decimal position sizes, and I ask PRT to correct this, please.

    I attach .itf files for both systems in the next post (this one is full).

     

    2 users thanked author for this post.
    #57401

    OK. Here are the 2 .itf files that PRT can use for debugging :

    #57404

    Vonasi, when PRT gets back to you for the error report, can you please forward them the link to this thread so they can use it for debugging ?

    Thanks a lot, and have a good week-end.

    #57425

    I put the link to this thread in my original communication with them.

    Thanks for your confirmation that it is not just my strategy that has these issues.

    #57439

    Thanks. Can you please post their replies here or a message when they have solved the problem ?

    #57455

    I certainly will. I have only had the standard reply telling me it may take a few days so far.

    #57457

    Very good analysis verdi55! I’m also using decimal position sizing and noticed sometimes that thinks simply didn’t add up but now you really made it obvious.

    Keep us posted vonasi if you should get an answer from PRT (I actually doubt it but would enjoy to be surprised :-)).

    #57458

    When you send them an official error report and describe enough details of the bug (and they need a code, of course), they will usually correct it within a few weeks and include the correction in an update. I have experienced this several times. Version 10.3 had quite some bugs when it was fresh.

    I assume (and expect) this all the more for a serious bug like this one here.

    #57460

    I’ll try to make it faster with a phone call. This should be fix asap IMO! Don’t know if this is still a problem with the new engine, anyone can make a test with a “prorealtime.com” account, the new version is already deployed there.

    #59641

    This problem is still happening when forward testing in demo in any strategy using decimal position sizing and cumulative orders.

    I noticed another strategy today with the same odd behaviour. It believes a position is open when in reality there is none. Image attached.

    So that is two weeks of forward test results that are completely useless and a waste of time. I will have to start again with a fixed position size. Anyone testing in demo with decimal position size and cumulate orders should do the same as you may believe you have a fantastic result when in reality it is a load of rubbish.

    #60867

    Hello Vonasi,

    Our technical team has tried the code that you attached here as an .itf file but they were not able to reproduce the problem. For this reason, I suggest you send a technical report following these instructions:
    – Go to the “Help” menu on the ProRealTime toolbar.
    – Click on “Technical support”
    – Giving as many details as possible, explain the issue you are having in the text box and mention the name of the code you are referring to.
    – To receive in depth assistance, it is necessary to analyze the code itself which is encrypted on our servers. To allow our technicians temporary access, please check the box marked “I authorize the decryption of the codes…”
    – Click “Send report”
    This will send us a report containing technical information concerning your platform, which will allow our technical team to run a diagnostic analysis of the issue you have come across.
    Thank you,
    All the best,

    Ilaria

    ProRealTime

    #60868

    Hello Verdi,

    About your codes (in the message you posted on 01/05/2018 at 4:50pm), our technical team informed us that the difference in the results is normal, since one can take decimal quantities with IG, both in ProBackTest and in real trading.

    In your first code, there will always be a rounded value, while in the second there can be a decimal value.

    Let’s take, for example, a loss of -900. In your first code:

    number = 1 + ((strategyprofit + 10000) / 125)=1+((-900+10000)/125)=73.8

    n = round(number)=round(73.8)=74

    In your second:

    number = 1 + ((strategyprofit + 10000) / 125)=1+((-900+10000)/125)=73.8

    n = round(number * 100) / 100=round(73.8*100)/100=round(7380)/100=7380/100=73.8

    Best wishes,

    Ilaria

    ProRealTime

Viewing 15 posts - 16 through 30 (of 39 total)

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