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 1 month ago by avatarkt.
Viewing 15 posts - 1 through 15 (of 16 total)
1 2
  • 03/12/2024 at 12:29 AM #229626
    kt

    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
    03/12/2024 at 2:43 AM #229627
    kt

    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
    03/12/2024 at 6:36 AM #229628
    JS

    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…

    03/12/2024 at 10:31 AM #229647
    robertogozzi

    try replaying

    by

     

    03/12/2024 at 8:10 PM #229663
    kt

    Thanks JS for the guidance.

    Thanks Roberto. Now both “d” and “volume” are protected from being zero.

    03/12/2024 at 11:33 PM #229665
    kt

    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

    03/13/2024 at 5:49 AM #229668
    kt

    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

    03/13/2024 at 8:29 AM #229672
    GraHal

    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??

     

    03/13/2024 at 9:24 AM #229676
    PeterSt

    Hi kt,

    At what Instrument and Timeframe are you testing this ?
    And is this IG or is it IB ?

    Peter

    03/13/2024 at 10:07 AM #229677
    kt

    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

    03/13/2024 at 12:29 PM #229692
    PeterSt

    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.

    03/13/2024 at 8:20 PM #229718
    kt

    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 ;))

    03/14/2024 at 3:57 AM #229738
    kt

    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 ….”

    03/14/2024 at 4:19 AM #229739
    PeterSt

    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 ?

    03/14/2024 at 9:47 AM #229749
    PeterSt

    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

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 16 total)
1 2

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
divide by zero protections
division by zero parameter error on 3 different strategies
division zero error

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