How to find a bot problem (negative value in indicators)

• 08/07/2022 at 11:35 AM #198666
  yoocesar

  Hi all,

  I write here to try to find some help to indentify what is wrong in one of my bots.

  I have a bot that running in BackTest have no problems, but in real, from time to time, the bot is stopped with a message saying that an indicator has been feed with negative values / cero. I only have an indicator with variable/calculated data and to ensure there are not negative values I use the ABS function. Also checking with the graph function (the only method to debug I know) I do not see any negative value or division by zero.

  I also have another previous version of this algo, with small changes, and no problems at all.

  Do you know any method / idea to look for the problem? I´m blocked since I cannot see any reason to stop the bot due to the reported reason and everything in Backtest is working nicely.

  Thanks a lot

  César

   

   

   

   

   

  

  yoocesar

  Participant

  Topics: 1

  Replies: 8

  Been thanked: 1 time
  08/07/2022 at 12:27 PM #198670
  GraHal

  It’s more likely to be a divide by zero due to no bar as in high, low, open and close all being the same value?

  Above is common on low Timeframe … what TF are you using?

  Have you got any divide by, / ***** in your code?

  

  GraHal

  Participant

  Topics: 220

  Replies: 9002

  Been thanked: 2293 times
  08/07/2022 at 12:32 PM #198672
  PeterSt

  Hello César,

  That is very unfortunate. And Yes, I too know the feeling of “not being able to continue”. Frustrating !

  If you would be able to share relevant pieces of code, I may be able to look into it and help finding the culprit. I mean, without anything *plus* the fact that Backtesting works fine, there is nothing much to do for us.

  You are aware of the Demo account with (PRT-)IG and that you are thus capable of testing without losing money ? I know of not many cases that Demo (/Paper Trading) would not be representative.

  Regards,
  Peter

  

  PeterSt

  Participant

  Topics: 73

  Replies: 2588

  Been thanked: 849 times
  08/07/2022 at 1:59 PM #198682
  yoocesar

  Thanks both for your support !!

   

  The algo works in 1h TF, so not very low.

  I have two divisions. One is using calculated values that I protected with the clasical one, when both values are equal (Division by zero) do something. I´ve just enhanced this protection to look not fot both values equal, just a very low diference between them (to prevent issues with resolution or something similar)

  The other division I have is something divided by close (typical volatilty filter with the std), so I would not expect a division by zero in this case, in principle.

  None of these divisions have changed between versions, and it is working without modifications in the first version no having this issue (what is confusing me a lot).

  I´ve just also protected all inputs to indicators with abs function to ensure no negative values are provided, even when no expected (i.e. a mean of the price)

  PRT should think in implementing a better debugging tool than the graph.

  Kind regards

  César

   

   

   

  

  yoocesar

  Participant

  Topics: 1

  Replies: 8

  Been thanked: 1 time
  08/07/2022 at 2:23 PM #198691
  PeterSt

  Can it possibly be so that the old version now also does not work any more ?
  If you don’t know the answer (you’d have to run in Live or Demo to know and that is not possibly today), is it possible that this is since about two weeks ?

  

  PeterSt

  Participant

  Topics: 73

  Replies: 2588

  Been thanked: 849 times
  08/07/2022 at 2:30 PM #198692
  yoocesar

  The old version is working properly. I have two instances, the old and the new one. The new one has been updated recently, yes.

  I´ve added a quit exception y the division by close is reached (close = 0), just to know if this is the reason. The other ones are protected.

  To me the main issue  is not knowing what is happening. The new version is better but nothing exceptional, so I can stop it. But I would like to know what is happening 🙁

   

   

  

  yoocesar

  Participant

  Topics: 1

  Replies: 8

  Been thanked: 1 time
  08/07/2022 at 2:31 PM #198693
  PeterSt

  yoocesar wrote:

  PRT should think in implementing a better debugging tool than the graph.

  I (really) am sure they are. But in this case that won’t help you because you can’t debug the Live (or Demo) environment. But, PRT I think will be able to do that themselves. For that, you would need to make a Technical Report (via the Help function in the main menu of PRT), denote a Technical Problem, leave the checkbox ticked they they are allowed to read your code (this is harmless and the people there can be trusted). Now *they* can build in debug code and hope that the culprit will occur.

  

  PeterSt

  Participant

  Topics: 73

  Replies: 2588

  Been thanked: 849 times
  08/07/2022 at 2:49 PM #198694
  GraHal

  Please be sure to let us know (the outcome re PRT Investigation) as many of us are ‘plagued’ with this same annoying Rejection error from time to time!

  Although several of us have managed to track down the offending bit of code; I generally add something like …  /max(1,High-Low) (was Rejected with High-Low due to divide by zero).

  

  GraHal

  Participant

  Topics: 220

  Replies: 9002

  Been thanked: 2293 times
  08/07/2022 at 4:43 PM #198714
  yoocesar

  I´ve just started a version will all protections enabled, including removal of a call to an indicator and embedding the code of this indicator in the algo.

  If it works, I will remove those protections step by step to know which one was the cause.

  As soon it fails again I will open a support request to PRT  following your instructions.

  I will keep you posted.

  Thanks all for your interest and support !

  César

   

  1 user thanked author for this post.

  GraHal

  

  yoocesar

  Participant

  Topics: 1

  Replies: 8

  Been thanked: 1 time
• Author
  Posts