ktParticipant
New
Hi Experts,
I’ve encountered a ‘divide by zero’ error in the automated trading while utilizing the code shared in the forum.
https://www.prorealcode.com/prorealtime-indicators/vwap-intraday/
d = max(1, intradaybarindex)
VWAP = SUMMATION[d](volume*typicalprice)/SUMMATION[d](volume)
if(intradaybarindex=0) then
sd= 0
else
sd= SUMMATION[d](max(abs(high–vwap),abs(vwap–low)))/d
endif
SDup1 = vwap+sd
SDlw1 = vwap–sd
SDup2 = vwap+sd*2
SDlw2 = vwap–sd*2
SDup3 = vwap+sd*3
SDlw3 = vwap–sd*3
// =====================
Recognizing that the ‘d’ variable is protected, I’ve adjusted the code to address this concern. The system is now running with the updated code, but I haven’t observed its performance yet. I’m uncertain if ‘sd’ was the root cause of the issue, the new code is a trial-and-error approach, and would greatly appreciate any insights or opinions.
new lines:
// =====================
d = max(1, intradaybarindex)
VWAP = SUMMATION[d](volume*typicalprice)/SUMMATION[d](volume)
KT
ktParticipant
New
no luck, the trading system said “The trading system was stopped due to a division by zero during the evaluation of the last candlestick. You can add protections to your code to prevent divisions by zero then backtest the system to check the correction.” with this code:
// =====================
d = max(1, intradaybarindex)
VWAP = SUMMATION[d](volume*typicalprice)/SUMMATION[d](volume)
1) I’ve updated the code to
// =====================
d = max(1, intradaybarindex)
if d <> 0 then
VWAP = SUMMATION[d](volume*typicalprice)/SUMMATION[d](volume)
endif
2) The code is currently set to operate within a ‘timeframe (1440 minute)’ under a system running at 5-second intervals. Do you think it would be advisable to relocate the code to a default or alternate timeframe that doesn’t correspond to a daily cycle?
KT
JSParticipant
Senior
Hi
@kt
If you use a time frame of 1440 minutes for your VWAP code, which corresponds to: 1440 minutes=24 hours=1 day, then there is no “IntraDayBarIndex”. The “IntraDayBarIndex” is then always equal to zero, while there is also a possibility that when reading (once) after 1440 minutes, the volume is equal to zero (so there is a chance of dividing by zero).
You can only use the VWAP intraday with timeframes smaller than 1 day, e.g. 1 minute or 5 minutes or…, otherwise there is no “IntraDayBarIndex” and therefore no code…
try replaying
/SUMMATION[d](volume)
by
/SUMMATION[d](max(1,volume))
ktParticipant
New
Thanks JS for the guidance.
Thanks Roberto. Now both “d” and “volume” are protected from being zero.
ktParticipant
New
Hi Roberto,
The system stopped with this line, fyi.
|
|
/SUMMATION[d](max(1,volume))
|
I presumed the max function should resolve the issue but it didn’t, strange..
kt
ktParticipant
New
Hi Roberto,
Apologies, I’m suspecting a zero volume that’s triggering the issue, and it’s also utilized elsewhere in the code. I’m addressing it now and will monitor the situation closely.
KT
I’ve been getting ‘divide by zero’ System stoppages overnight all week since Sunday … I don’t think IG have sorted the reason yet … unless this is the new Norm??
Hi kt,
At what Instrument and Timeframe are you testing this ?
And is this IG or is it IB ?
Peter
ktParticipant
New
Hi Peter,
Mainly forex – i.e., eur/usd, usd/jpy, aud/usd, and gbp/usd. The timeframe is 10 seconds. All instruments exhibited similarly by giving the divide-by-zero error.
kt
Bummer.
Say that I have a kind of trick to see things go wrong in backtesting, which normally go right but fail on a division by 0 in Live/Demo. But the trick shows nothing wrong.
What I do notice is that IG and IB are so wildly different for sd (your variable) that it is hard to believe that both can be used at the same time – one of them has to be quite wrong. Of course we have the knowledge that the volume with IG is a derivative.
ktParticipant
New
Aha.. it is IG by the way. (Just noticed I missed the question)
so far my system is running fine after I removed sd, and protected vol with max (minimum) one.
what with the derivative volume? how bad/good it is? ( I know this is not a coding question so no stress ;))
ktParticipant
New
No luck again. It seems that max(1,volume) function still triggers a divide-by-zero error in the live trading system. I’ve updated the code with “if volume <> 0 then ….”
When does this actually happen ? Right away after handing the system to ProOrder ? At some always same time ? After some always same time ? randomly but not right from the start ?
The Volume never is 0, so checking for that won’t help. The volume is at least one (I checked for your several instruments), although I don’t think that is even correct (could be a source of error in itself).
Why would the issue be per se in the lines of code you gave ? Is it possible that you attach the full .itf ?
I have some special news on this …
For the first time I have been subject to similar myself and after fighting with this for 10 days or so and many thrown-outs and restarts, I could find the culprit per means of special trick which does not work here (I mentioned that in my first post in this topic). But *because* I initially could not find it – always claiming it would be on my own bad-coding behalf – but what to do with 5000 lines of code – I escalated this to PRT and a kind of urged for something that could be done on thee PRT server(s), so that ProRealTime could see at what line of my code it goes wrong.
I was just called with this :
“If you experience the division by zero error a next time, make a Technical Report (via the Help menu) by means of the AutoTrading tab, announce that this is about a Division by Zero error, tick the checkbox that PRT is allowed to see your code, which provides a technical means to ProRealTime engineers to see where the code goes wrong. You won’t be called with questions about your code (can’t explain 5000 lines of code anyway) – this will just work out.”
Of course I will only believe this when I see it happening and working out, but alas.
kt, I would urge you to trial this. If it indeed it so that your further code does not cause this, the situation will be different, but the offer remains the same : “We at PRT will find the cause”. Thus also when it is a PRT bug (that’s my own interpretation of it).
So easy enough, just make that Technical Report. And no need to be afraid that someone steals your code (I sorted out the decency of that long ago).
Peter
