Cumulate orders and decimal position size strange backtest results

• 12/22/2017 at 9:31 PM #56394
  Vonasi

  I was working on a strategy that used CumulateOrders=True which added to a position if price moved in our favour and the same entry criteria were met again. The results seemed quite promising so I added some code to vary position size based on increasing and decreasing equity levels which opens positions sizes to 2 decimal places and then the test results went all weird with large period not on the market.

  The code I added was this:

  Capital = 10000 Equity = Capital + StrategyProfit PositionSize = Max(1, Equity * (1/Capital)) PositionSize = Round(PositionSize*100) PositionSize = PositionSize/100

  1 2 3 4 5

  Capital = 10000 Equity = Capital + StrategyProfit PositionSize = Max(1, Equity * (1/Capital)) PositionSize = Round(PositionSize*100) PositionSize = PositionSize/100

  Image 1 is with fixed position size and image 2 is with the variable position size.

  Any ideas why the latter does not work as it should?

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  12/22/2017 at 9:51 PM #56397
  Nicolas

  Graph positionsize? Does it give right calculations?

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4773 times
  12/22/2017 at 10:38 PM #56399
  Vonasi

  Hello Nicolas

  It appears to be as expected. Image attached.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  12/22/2017 at 10:43 PM #56401
  Vonasi

  I am also getting very weird results from Forward Testing. Image attached is with fixed position size.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  12/23/2017 at 12:59 PM #56425
  Nicolas

  How many decimals has your positionsize variable?

  I’d like to help, but I can’t replicate the problem.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4773 times
  12/23/2017 at 3:25 PM #56432
  Vonasi

  2 Decimal places created with the following bit of code:

  PositionSize = Round(PositionSize*100) PositionSize = PositionSize/100

  1 2	PositionSize = Round(PositionSize*100) PositionSize = PositionSize/100

  I can attach an itf of the complete code if you want. It is a bit of a work in progress but maybe it will help – although the only think I changed between working and not working was the positionsize bit of code.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  12/23/2017 at 3:52 PM #56437
  Vonasi

  Here’s the itf file if it is of any help Nicolas.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  12/24/2017 at 9:51 PM #56514
  verdi55

  The system counts positions that do not exist. The longest one lasts for almost 2 years, but there is no position, in fact. This is why no new position is opened, I guess. See the backtest report :

  

  I had similar problems with backtests when I used position sizes with 2 decimals. The backtest report showed positions over huge amounts of bars that did in fact not exist. No problems arose however in backtests, when integer values for the position size were used.

  And, fortunately : I had no problems with position sizes having 2 decimals in live trading. But the backtests were still wrong.

  When you look closely at the line of positions in the backtests with decimal position sizes, you see very small “spikes” at the times when the non-existing positions are open:

  

  Or sometimes you see an additional baseline, that is absent when integer position sizes are used.

  With integer position sizes, the spikes ar gone and it looks like this :

  

  There is definitely a bug with fractions for position sizes, I think.

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  12/24/2017 at 10:23 PM #56519
  verdi55

  It may be that in an old version of PRT, before decimals as position sizes were possible, somewhere in the source code only integers for position sizes were allowed and that one of these limitations is still there. This is only an unverifiable assumption from my side, of course.

  But ProRealtime can debug this quite soon, I think.

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  12/29/2017 at 10:53 PM #56844
  Vonasi

  I wrote another code today also with decimal position size and cumulate orders and all was working fine until I added a second entry IF THEN set up with same conditions and entry only if close is higher than PositionPrice and then it appeared to think a position was open when in fact none were.

  IF Not Onmarket and Uptrend and RangeOK and MA2OK and MAOK and timeok and not daysForbiddenEntry THEN BUY PositionSize contract at Market ENDIF IF Onmarket and Uptrend and RangeOK and MA2OK and MAOK and timeok and not daysForbiddenEntry and close > PositionPrice THEN BUY PositionSize contract at Market ENDIF

  1 2 3 4 5 6 7

  IF Not Onmarket and Uptrend and RangeOK and MA2OK and MAOK and timeok and not daysForbiddenEntry THEN BUY PositionSize contract at Market ENDIF   IF Onmarket and Uptrend and RangeOK and MA2OK and MAOK and timeok and not daysForbiddenEntry and close > PositionPrice THEN BUY PositionSize contract at Market ENDIF

  I am not sure why it closes all positions fully with just one entry criteria but does not with two. Any ideas Nicolas?

  This was backtesting on my live account not demo.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  12/29/2017 at 11:02 PM #56846
  verdi55

  The conclusion is very simple : Report this to PRT. It is a bug, and they will correct it, according to my experience.

  

  verdi55

  Participant

  Topics: 2

  Replies: 311

  Been thanked: 84 times
  12/30/2017 at 10:41 AM #56857
  Nicolas

  To get onmarket = true, you need that the order has existed at least during one period. I don’t know if it’s related but that’s a common issue when programming. Sorry if I can’t explore more your problem, but I’m on leave until end of first week of January 🏖️

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4773 times
  12/30/2017 at 12:12 PM #56862
  Vonasi

  OK Nicolas – enjoy your holiday and log out of the website now or it isn’t a holiday!

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/03/2018 at 12:43 PM #57099
  Vonasi

  I found a solution that fixed these weird back testing results. I put the strategy live on demo and it came back with a preloadbars insufficient that stopped the strategy. So I put a DEFPARAM PreLoadBars = 10000 in the strategy and now it backtests just fine. I don’t understand why – but it fixed the problem.

  I now have a different issue. In the process I ended up with two identical strategies. Letter for letter, number for number, word for word identical and when I backtest them I get different results. It is on  4 hour time frame so it is not a case that they have different start points. the difference on returns on exactly the same number of bets is considerable. Images attached.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  01/03/2018 at 4:46 PM #57151
  Vonasi

  Please ignore the solution regarding preloadbars in the last post as it was not the solution to this problem – I forgot to turn the money management back on for the test! What a 42 carat plonker.

  I still have the second problem of differing results for identical strategies though.

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
• Author
  Posts