Cumulate orders and decimal position size strange backtest results

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

This topic contains 38 replies, has 5 voices, and was last updated by avatar verdi55 1 year, 3 months ago.

View all attachments
Viewing 15 posts - 1 through 15 (of 39 total)
  • #56394

    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:

    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?


    Graph positionsize? Does it give right calculations?


    Hello Nicolas

    It appears to be as expected. Image attached.


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


    How many decimals has your positionsize variable?

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


    2 Decimal places created with the following bit of code:

    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.


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

    1. Momentum-Breakout.itf

    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.


    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.


    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.

    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.


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


    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 🏖️


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


    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.


    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.

Viewing 15 posts - 1 through 15 (of 39 total)

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