@Ilaria : This is nonsense.
Your team needs to examine the fake positions and the chart spikes that appear in the code with decimal positions. Do not try to get out of the problem with the usual excuses.
I did not say that there should not be any difference between the 2 codes : Of course it makes a difference whether you use decimal or integer position sizes. The difference between the 2 codes is not the problem. The problem is that your team does not even try to understand nor to solve this serious bug.
In the code with decimal position sizes you get fake positions in the report that the chart does not show, and there are strange spikes showing up in the chart.
All of this is described in detail in post #57395.
You need to check this further and solve the problem, please, as this is a serious and entirely reproducible bug in PRT !
Hello Illaria
I will try to send a technical report with with permission to access the code when I have time – I am rather busy at the moment.
I do find it slightly hard to understand why your technicians were unable to replicate the issue and have taken so long to come to this conclusion. Verdi55 – another poster in this forum – was able to write a quick code and test it with and without decimal position sizing and get exactly the same problem with his results as I did with my strategy – and that was over three weeks ago. More than three weeks is a long time not to achieve what he managed in probably less than an hour!
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
Your technicians seem to be missing the point of what the problem is. The problem is that positions appear to not be completely closed when using decimal position sizing and so a partial position is kept open when in fact there should be no position open at all. This also stops other positions from opening if only one position at a time is allowed and means that backtest results are completely inaccurate.
@Ilaria :
Please use and examine the codes posted in #57401. Both codes should open all positions exactly at the same time and close them at the same time.
Only position sizes are slightly different among the codes, with an integer position size in system-with-integer-positions.itf and with decimal position sizes in system-with-decimal-positions.itf .
However, the system with decimal position sizes lists positions in the backtest report that are not shown in the chart. These false positions have a longer duration than they could according to the code.
According to the code, a new position is opened exactly every 20 bars. No position can therefore have a longer duration than 20 bars. This is displayed correctly in the system with integer position sizes.
However, in the system with decimal position sizes, false positions are listed in the backtest report that have a longer duration than 20 bars.
According to the code, this is completely impossible and this is a bug. None of these erroneous positions is shown in the chart, but instead we see strange little spikes at the times when the positions with longer duration than 20 bars show up in the report.
Please find out where these erroneous positions come from, why the spikes in the chart are shown, and of course, please correct this persistent and annoying bug. As Vonasi said, it makes meaningful backtests with decimal position sizes impossible, and I have experienced it in many other systems as well.
Live trading works fine and as expected with decimal position sizes, so far.
To be honest, I have no serious problem with this bug. I know how to evaluate results in my backtests, even when they are not accurate, and in doubt I take backtests with integer position sizes. Then I may get kind of digital steps between position size 1 and 2, for example, but sometimes overall results of a self-growing system are even better with these steps than with two-digit decimal position sizes.
So, this was more of an intellectual challenge to discover a bug than a real problem in real trading life.
When the new engine does not have this bug, I don’t care.
@ilaria : Sorry for my strong initial words, but as a former scientist, I still do not like when people do not spend any effort. May be I’m wrong in the trading business, then…
And to make serious money, I’d rather become a broker’s successory.
Hello Verdi,
Our technical team has had a second look at your codes and, indeed, thanks to the information you wrote in your reply, this time they have been able to reproduce the issue you reported. They are currently working on it.
I will give you news as soon as they find the source of the problem.
Best wishes,
Ilaria
ProRealTime
It appears that this bug has been corrected in the latest update. The test system is now working properly, and so are my real systems with decimal position sizes. All positions shown in the backtest now have the correct number of bars.
Thank you !
The strange spikes between positions in the charts are still there, but who cares.
