You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I did not say there were errors. I said their were warnings and listed them for you.
Don't code for "human readability". Code for the "machine". Code for efficiency. Only think about the "human" part in the final stages when plotting or outputting to text.
If you have to scale, then scale by the Tick Size or by the Point Size, because those are the units you would use. Don't just scale by some arbitrary number that you think is appropriate.
Also, ATR as the name says, is an average, and averages do not align to exact whole numbers, even if you scale them by the tIck size or point size. You have to be very wary of this when planning your logic.
However in this case, neither the ATR not the decision logic for the ATR is for "humans". It is only for internal "machine" usage. So make the code efficient. Instead, scale the input parameter. You can supply the parameter in units of "points" or "ticks" and then scale it to price range, given that the iATR data will be price range.
I don't yet know if this is the cause of your indicator malfunction or not, but if you eliminate all problematic code from that get go, then there will be less "suspect" code to have to debug to find issues. If you let the "small" things slide, they can easily build up into a cascade effect leaving you not knowing what is going wrong.
My aim is not to find the bugs for you or to debug it. My aim is to help you clean up the code and its logic to the point where you yourself will see the problem more easily.
That being said, with the aim of reaching the first milestone of having the code "flawlessly" compile, with no errors or warnings, I would like you to tackle this first part, of rewriting the "isATRCrossedUp" function and the handling of the "atrCrossLevel" parameter, so that the code will compile cleanly.
Once that milestone is completed, we will proceed to the next one. Here is my rendition of how I would rewrite this part (using my own style of coding) to resolve the issues mentioned so far. It is not the only solution. It is merely one solution. Each coder will have their own way of looking at things, and mine is just one of many. Please note, that the code still has a "logic bug" in it. I have left it there on purpose so that we can discuss it later. It has to do with the problem of testing for equality between floating point numbers.
My apologies, you did say warning. However, I'm still left not knowing where that warning came from. I don't see it anywhere. I do indeed see the other 2 warnings though.
And I'm all for working it out myself with some guidance. I would much rather learn where my problems are and end up having less of them in the future than to have someone hand me the answer without learning anything. :)
Challenge accepted! I will post back when I'm done.
Ok, the decision I made was to keep the code as simple as possible. To that end, I decided to not worry about converting the atr values at all. I understand what they mean and by cutting out conversion it's a little big simpler to look through all the code. Do that end, here is my end result:
All other code is the same and the warnings are gone.
The first warning comes from when you compile the REX indicator which you use:
Currently the REX indicator has one warning:
Do you remember that in one of my previous posts I alerted you about the problems with testing for equality with floating point numbers?
Well, the fact is that testing for equality with "double" or "float" is almost impossible due to the inherent way in which numbers are converted to and from decimal and binary. Here are some options for your code above, given that ATR is supposed to always be a positive value:
EDIT: As for "mATRCur >= atrCrossLevel", I will address this later as I will be giving you a different way to detect the cross. Your current logic is prone to fail, so I will show you a more robust way to detect the cross.
Here is some suggested reading:
Do you remember that in one of my previous posts I alerted you about the problems with testing for equality with floating point numbers?
Well, the fact is that testing for equality with "double" or "float" is almost impossible due to the inherent way in which numbers are converted to and from decimal and binary. Here are some options for your code above, given that ATR is supposed to always be a positive value:
Here is some suggested reading:
As for the warning, I still don't see it on my logs.
Metaeditor
And the MT5 Log:
I repeat ... The first warning is from when you compile the "REX.mq5" file.
This is my new code:
That is why I said that I would let that warning slip. Because it is not your code that is at fault. Someone else was not careful about it.
I repeat ... The first warning is from when you compile the "REX.mq5" file.
Yeah I figured out what you meant and edited my last post. Apologies.
I gotcha now, I think we are on the same page.