Cumulate orders and decimal position size strange backtest results

• 01/05/2018 at 11:24 AM #57340
  Vonasi

  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.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/05/2018 at 1:37 PM #57363
  verdi55

  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.

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  01/05/2018 at 1:56 PM #57366
  Vonasi

  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.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/05/2018 at 4:50 PM #57395
  verdi55

  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, :

  Test system with integer position sizes

  //Test system with integer position sizes (0 decimals), DAX 1 EUR Mini contract, 1 minute chart number = 1 + ((strategyprofit + 10000) / 125) n = round(number) If n <= 1 then n = 1 endif b = 0 If a = 0 and barindex = BIin + 20 then buy n contracts at market a = 1 b = 1 BIin = barindex endif If a = 1 and b = 0 and barindex = BIin + 20 then sellshort n contracts at market a = 0 BIin = barindex endif set target pprofit 10 set stop ploss 10

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  //Test system with integer position sizes (0 decimals), DAX 1 EUR Mini contract, 1 minute chart   number = 1 + ((strategyprofit + 10000) / 125)   n = round(number)   If n <= 1 then n = 1 endif   b = 0   If a = 0 and barindex = BIin + 20 then buy n contracts at market a = 1 b = 1 BIin = barindex endif   If a = 1 and b = 0 and barindex = BIin + 20 then sellshort n contracts at market a = 0 BIin = barindex endif   set target pprofit 10 set stop ploss 10

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

  Test system with decimal position sizes

  //Test system with decimal position sizes (2 decimals), DAX 1 EUR Mini contract, 1 minute chart number = 1 + ((strategyprofit + 10000) / 125) n = round(number * 100) / 100 If n <= 1 then n = 1 endif b = 0 If a = 0 and barindex = BIin + 20 then buy n contracts at market a = 1 b = 1 BIin = barindex endif If a = 1 and b = 0 and barindex = BIin + 20 then sellshort n contracts at market a = 0 BIin = barindex endif set target pprofit 10 set stop ploss 10

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  //Test system with decimal position sizes (2 decimals), DAX 1 EUR Mini contract, 1 minute chart   number = 1 + ((strategyprofit + 10000) / 125)   n = round(number * 100) / 100   If n <= 1 then n = 1 endif   b = 0   If a = 0 and barindex = BIin + 20 then buy n contracts at market a = 1 b = 1 BIin = barindex endif   If a = 1 and b = 0 and barindex = BIin + 20 then sellshort n contracts at market a = 0 BIin = barindex endif   set target pprofit 10 set stop ploss 10

  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.

  

  Now, let’s compare the 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 :

  

  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 :

  

  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.

  Kovit, Nicolas

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  01/05/2018 at 4:52 PM #57401
  verdi55

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

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  01/05/2018 at 4:54 PM #57404
  verdi55

  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.

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  01/05/2018 at 7:40 PM #57425
  Vonasi

  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.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/05/2018 at 9:08 PM #57439
  verdi55

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

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  01/05/2018 at 9:53 PM #57455
  Vonasi

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

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/05/2018 at 10:10 PM #57457
  Despair

  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 :-)).

  

  Despair

  Blocked

  Topics: 97

  Replies: 1034

  Been thanked: 218 times
  01/05/2018 at 10:22 PM #57458
  verdi55

  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.

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  01/05/2018 at 10:45 PM #57460
  Nicolas

  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.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4774 times
  01/16/2018 at 11:52 AM #59641
  Vonasi

  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.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/29/2018 at 4:24 PM #60867
  Ilaria

  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

  

  Ilaria

  Participant

  ProRealTime

  Topics: 0

  Replies: 27

  Been thanked: 11 times
  01/29/2018 at 4:26 PM #60868
  Ilaria

  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

  

  Ilaria

  Participant

  ProRealTime

  Topics: 0

  Replies: 27

  Been thanked: 11 times
• Author
  Posts