smpParticipant
Average
Guys,
In my code, I called up an indicator but every time it tries to run, it fails and gives the same error (Attached below). I have DEFRAM Preloadbars set to 10000 as suggested in the error message; I also have loaded the code into a chart with units set to over 10000 units. However, it will still not run
It backtests no problem at all.
Using Version 10.3
Any ideas?
What is the max period used by any indicator of your system? Custom or default one?
smpParticipant
Average
I use the default 10000 units now. When I first installed I used 200 units but changing from 200 to 10000 seems to have made no difference at all
Sorry but you did not answered the question. In your code, are you using indicators suchs as EMA, RSI, etc? If yes, what is the maximum period used in the code?
smpParticipant
Average
Sorry,
I enclose the indicator called “KEY”
Also, the code that calls it up
Hope this helps
Well, after inspection of the provided codes, I do not see any special reason why you get this error message. You should send an error report through the assistance tool of the platform.
smpParticipant
Average
Thanks, reported issue to PRT
smpaxton please let us know the PRT response.
So often Reject error messages do not appear logical and it is so frustrating for us all getting rejected in Live and yet Backtest shows no problems.
I would like to see PRT doing something toward aligning Live running and backtest re reject errors … even if it is only a series of hints / possible suggestions that gets flagged up after a backtest has run. Not stop / reject the backtest as that would mean more load of PRT servers, just flag up possible reasons and possible solutions to code that may / is likely to be rejected in Live.
I can feel another Suggestion for Improvement to PRT coming on! 🙂
smpParticipant
Average
GraHal,
Yes, no problem. I do know the IG PRT team and spoke about the issue yesterday and they assure me they will be looking at it as a priority as it’s not the first time this has happened. It’s one of the many reasons I will not use V11 of PRT yet as v11 has too many bugs that just are not been resolved!
smpParticipant
Average
Guys,
here is the final response from IG PRT, see blow. It does not make sense! Unless anyone can explain this!
We’ve been guided by Eduard at PRT that your code issue has been resolved with the below feedback:
His code is working on a 4 hours UT but not on 1hour UT.
The error message is :
“The trading system was stopped due to a division by zero in one of its sub-functions during the evaluation of the last candlestick.”
After analyzing we saw that last candlestick has the same high and the same low as you can see below :
20210917:170000,20210917:180000,4419.08,4419.08,4419.08,4419.08,3
+ in his code you can see this line:
high= highest[period](high)
llow = lowest[period](low)
temp = 0.66 * ((mean – llow) / (hhigh – llow) – 0.5) + 0.67 * Ld36
Therefore you have a division by 0 (because here low = high):
high = low => (mean – llow) / (hhigh – llow)
If the clients wants to trade on this UT he has to use a protection in case of high = low.
Below you’ll find an example of protection:
if hhigh-llow<> 0 then
temp = 0.66 * ((mean – llow) / (hhigh – llow) – 0.5) + 0.67 * Ld36
endif
JS
preloadbars can be det over 5000? I have out it on 200000 on some of my robots?
It does not make sense! Unless anyone can explain this!
Looks to me that IG have got mixed up and sent you the solution to somebody else’s problem (divide by zero).
I have out it on 200000 on some of my robots?
PreLoad bars cannot be more than 10,000 … no matter what we set it to.
Default preload bars is 2000 and the max available is 10000.
If the result of high-low is zero, then the division is impossible.
They suggested a solution.
I think a better solution would be:
x = hhigh – llow
if x = 0 then
x = 1
endif
temp = 0.66 * ((mean – llow) / x – 0.5) + 0.67 * Ld3
