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
Ok, here is continuing our saga ...
Next, some test code to simply copy and display the data obtained from iATR. Put up this indicator and the standard ATR indicator so as to compare the two.
Then look at the code and analyse, question and comment on it.
Don't worry. We will slowly build it up again to the full code you are developing.
Ok, the first thing I notice is that it has an extra decimal place compared to the regular ATR. I have yet to figure out why that is. But, it might effect the the outcome when I was multiplying it by 100,000.
After that, it looks to me like the beginning of your onCalc function is significantly simpler than I have it.
And as always, the entire code looks very clean and easy to look through.
Other than that, it seems to be fairly self explanatory.
Floating-point has an infinite number of decimals, it's you, not understanding floating-point and that some numbers can't be represented exactly. (like 1/10.)
Double-precision floating-point format - Wikipedia
See also The == operand. - MQL4 programming forum (2013)
If you want to see the correct number of digits, convert it to a string with the correct/wanted accuracy.
question about decima of marketinfo() - MQL4 programming forum (2016)
Floating-point has an infinite number of decimals, it's you, not understanding floating-point and that some numbers can't be represented exactly. (like 1/10.)
Double-precision floating-point format - Wikipedia
See also The == operand. - MQL4 programming forum (2013)
If you want to see the correct number of digits, convert it to a string with the correct/wanted accuracy.
question about decima of marketinfo() - MQL4 programming forum (2016)
Actually, all I meant was that his ATR indicator had more decimal points showing. I do realize that floating point numbers have an infinite number of decimals. Please forgive me for not being completely specific with my terminology.
Nor was I implying it was a big thing or a problem. I was simply noting the difference between the two indicators because that was what I was asked to do.
Also, I do recognize that some numbers cant be represented exactly, that was one of the last lessons Fernando went over with me. Nor is that related to my observation of more displayed decimal places.
No, it does not have extra decimal points. Internally the values are in full double precision floating point. It is only when displayed that we need to consider the number of decimal digits.
For this simple code I have not set the maximum number of visible decimal digits and as a consequence, it is using the default of 8 digits instead of the number of digits of the underlying symbol.
This I will add to the code later, when we start considering the actual plotted buffers and not the calculated ones. Since ATR will be a calculation buffer, I did not bother doing that yet.
Next, since the aim is for you to keep learning and understanding it step by step, I am going to ask you to take my simple code, and modify it to plot the two REX buffers instead of the ATR. Just the two REX plots, nothing else.
After that, I will introduce a few support functions to help clean it up further as we approach your intended objective.
By the way, if you wondering why I use those "weird" prefixes in my variable names, it is to help identify them more easily.
I use "i_" for inputs and "g_" for global variables. I use "a" for arrays, "h" for handles, "n" for integer based numbers, "db" for double floating point, and several others not present in this code.
So "g_adbAtrBuffer" is a global variable of an array of double precision floating point for the ATR buffer, ...
and "i_nAtrPeriod" is a input variable of an integer numeric for the ATR period.
This is not necessary. It is just the coding style I am adopting. You should use what ever style you feel comfortable using that helps you read your code more easily.By the way, if you wondering why I use those "weird" prefixes in my variable names, it is to help identify them more easily.
I use "i_" for inputs and "g_" for global variables. I use "a" for arrays, "h" for handles, "n" for integer based numbers, "db" for double floating point, and several others not present in this code.
So "g_adbAtrBuffer" is a global variable of an array of double precision floating point for the ATR buffer, ...
and "i_nAtrPeriod" is a input variable of an integer numeric for the ATR period.
This is not necessary. It is just the coding style I am adopting. You should use what ever style you feel comfortable using that helps you read your code more easily.I figured that's what it was. The only one I didn't figure out was db.
Ok, so I wrote it all over again in my own hand and more or less in my style. Helps me to process the everything mentally.
And it seems to work. :)
When writing code, get into the habit of writing proper comments. You changed the code but left the comments still referring to the ATR stuff, instead of updating them to reflect the new context, namely the REX indicator. This may seem inconsequential, but those comments are what will allow you to read the code (especially in the future) and give you a better sense of what it is doing.
Always remember to have comments on the inputs, because they are displayed in the Indicator’s properties/parameters window. You want to know what the parameters are and how to set them, instead of just having some cryptic variable names.
So, as an exercise to improve your code readability, change the ATR comments, add comments to the parameters, and add new comments to those sections of code that seem cryptic to you so that you can remind yourself of what they do.
If, however, you decide you don’t want to do, then let me know, and I will move on with the next part.
By the way, I use “db” for double and “dt” for datetime; hence the reason I did not simply use a single character such as “d”.
When writing code, get into the habit of writing proper comments. You changed the code but left the comments still referring to the ATR stuff, instead of updating them to reflect the new context, namely the REX indicator. This may seem inconsequential, but those comments are what will allow you to read the code (especially in the future) and give you a better sense of what it is doing.
Always remember to have comments on the inputs, because they are displayed in the Indicator’s properties/parameters window. You want to know what the parameters are and how to set them, instead of just having some cryptic variable names.
So, as an exercise to improve your code readability, change the ATR comments, add comments to the parameters, and add new comments to those sections of code that seem cryptic to you so that you can remind yourself of what they do.
If, however, you decide you don’t want to do, then let me know, and I will move on with the next part.
By the way, I use “db” for double and “dt” for datetime; hence the reason I did not simply use a single character such as “d”.
Going to do this right. Not skipping. :)