vwap – divide by zero error
Forums › ProRealTime English forum › ProOrder support › vwap – divide by zero error
- This topic has 15 replies, 5 voices, and was last updated 8 months ago by kt.
-
-
03/12/2024 at 12:29 AM #229626
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) thensd= 0elsesd= SUMMATION[d](max(abs(high–vwap),abs(vwap–low)))/dendifSDup1 = vwap+sdSDlw1 = vwap–sdSDup2 = vwap+sd*2SDlw2 = vwap–sd*2SDup3 = vwap+sd*3SDlw3 = 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)// =====================KT03/12/2024 at 2:43 AM #229627no 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 thenVWAP = 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?KT03/12/2024 at 6:36 AM #229628Hi @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…
03/12/2024 at 10:31 AM #229647try replaying
1/SUMMATION[d](volume)by
1/SUMMATION[d](max(1,volume))03/12/2024 at 8:10 PM #22966303/12/2024 at 11:33 PM #22966503/13/2024 at 5:49 AM #22966803/13/2024 at 8:29 AM #22967203/13/2024 at 9:24 AM #22967603/13/2024 at 10:07 AM #22967703/13/2024 at 12:29 PM #229692Bummer.
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.
03/13/2024 at 8:20 PM #229718Aha.. 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 ;))
03/14/2024 at 3:57 AM #22973803/14/2024 at 4:19 AM #229739When 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 ?
03/14/2024 at 9:47 AM #229749I 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
-
AuthorPosts
Find exclusive trading pro-tools on