Question to the MQL4 masters. Again about Double Compare. - page 7
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
This conversation seems to go on indefinitely. By the time a new user has gained the proper experience and knowledge, he usually has time to bump into normalisation several times.
Perhaps in MT5 it makes sense to forcibly limit the accuracy of real numbers when performing comparison operations, say, to 8 decimal places (i.e. to forcibly execute NormalizeDouble() with digit=8).
If the comparison operation will be used repeatedly (in recurrent calculations, etc.), then rounding to 8 digits on the input, the output error can be commensurate with 1.
I had such an experience with calculating SmoothedAvarege, calculating it in my application a year ago. After that, I'm trying to choose such methods of working which don't affect the digit capacity of doubles.
Or, as gravity001 suggested, switch to INTam (which, as you understand, is very time-consuming).
Perhaps in MT5 it makes sense to forcibly limit the accuracy of real numbers when performing comparison operations to, say, 8 decimal places (i.e. to forcibly perform NormalizeDouble() with digit=8).
However, not only user-defined operations slow down the terminal, but operations hidden from it as well. It seems to me preferable to simply introduce the ComparePrice function into the language. By the way, just like Irtron, I consider Point/2 a natural measure (perhaps better Point *0.5). To avoid dividing/multiplying every time, this half can be made a predefined variable. Until that does not exist, you can enter such a variable yourself and calculate it once at first start of start. Although, developers can make function of double comparison with predefined accuracy, i.e. the same, but with digits instead of Point/2.
You've made a mess of it... :)
Comparison of floating numbers is done by comparing the modulus of difference with a small threshold.
Return (fabs(d1-d2) < 1e-10) for example.
What's the point of muddling the waters... The NormalizeDouble(...) function is needed for nice reports, nothing more.
But you're missing the point, you need to read more carefully. The essence of the question is the programming style in general, and in the specific case of MT4.
You've made a mess of things... :)
Comparison of floating numbers is done by comparing the modulus of difference with a small threshold.
Return (fabs(d1-d2) < 1e-10) for example.
What's the point of muddling the waters... The NormalizeDouble(...) function is just for nice-looking reports.
But you're missing the point, you need to read more carefully. The essence of the question is the programming style in general, and in the specific case of MT4.
You'd better tell us what the point of this question is. Otherwise hints - I don't! understand :)
If we're talking about speed, modern processors perform floating point operations
almost as fast as integer ones. As for STYLE, sorry, pragmatism rules...
When ASHIPS are around, what kind of style are we talking about... Just as long as it works. ...
Otherwise there is no other problem than comparing two numbers :))))))))
I didn't expect anything like that from you. You mustn't do that in any case!
If the comparison operation will be used repeatedly (in recurrent calculations, etc.), then if you round up to 8 digits on the input, the output error can be commensurate with 1.
I had such an experience with calculating SmoothedAvarege, calculating it in my application a year ago. After that, I'm trying to choose such methods of working which don't affect the digit capacity of doubles.
Or, as gravity001 suggested, switch to INTam (which, as you understand, is very time-consuming).
Wait a minute. There is no need to jump to conclusions.
Firstly. I do not propose to forcibly round the actual value of the real variable itself. I propose to force rounding of compared values (copies) of variables when calculating the result of a comparison operation (for the default case). And of course, the actual value of a variable must not be touched. In this case, no other calculated values would be affected, because the original values of the variables used in comparison operations retain their values, and errors in cyclic calculations would not accumulate.
Second. I said that in order to eliminate errors with harsher consequences, we can go this way. However, in order to provide more demanding calculations as well, it is necessary to preserve the possibility to useNormalizeDouble() function with specified parameters.
So my suggestion does not limit the capabilities of the language, but extends them.
However, taking into account that in comparison operations, as a rule, price values are used (i.e. digit = 4), in the vast majority of cases this error simply will not occur. Thus, using the proposed technology will reduce the number of errors that lead to unpredictable consequences.
In the absence of this, you can enter such a variable and calculate it once at the first start of start.
You can't.
Or rather, you can write program strings, but no one (including the developers) will guarantee that the value of this variable will remain strictly unchanged throughout the lifetime of the EA. It is not about the accuracy of the program code, but about the technological features of calculations and technological rules for storing the values of variables. If it were not so, this problem would not even exist.
As it currently stands, the initial value of 123.00000000000 variable can appear as 122.99999999999999 by the moment it is used in calculations. This is despite the fact that the variable's value has never changed since it was created and was only called by the program to take part in other calculations.
This is actually why there was all this fuss. This is why we created the necessity of using NormalizeDouble() as close to actual calculation as possible, preferably directly in the condition of if, for, while statements.
And while that's not available, you can enter such a variable yourself and compute it once on the first start of start.
You can't.
Or rather, you can write program strings, but no one (including the developers) will guarantee that the value of this variable will remain strictly unchanged throughout the lifetime of the EA. It is not about the accuracy of the program code, but about the technological features of calculations and technological rules for storing the values of variables. If it were not so, this problem would not even exist.
As it currently stands, the initial value of 123.00000000000 variable can appear as 122.99999999999999 by the moment it is used in calculations. This is despite the fact that the variable's value has never changed since it was created and was only called by the program to take part in other calculations.
This is actually why there was all this fuss. That's why I needed to use NormalizeDouble() as close as possible to actual calculation, preferably right in the condition of if, for, while statements.
Golly, I think I'm beginning to understand what all the fuss is about...
All in all, I guess you don't have to make anything up. It all depends on the situation. What's the goal? If two numbers can differ in mantissa 0.1, and if it is CRITICAL, it is one thing, if it is not important, it is another. It depends on what is being compared with each other. But the FLEXIBILITY, given by a REAL compiler without frills, is a REAL and necessary thing, IMHO.
:)
Golly, I think I'm beginning to see what all the fuss is about...
Generally speaking, I don't think there's ANYTHING to be made up. Because it all depends on the specific situation. What's the goal? If two numbers can differ in mantissa 0.1, and if it is CRITICAL, it is one thing, if it is not important, it is another. It depends on what is being compared with each other. But the FLEXIBILITY, given by a REAL compiler without frills, is a REAL and necessary thing, IMHO.
:)
I cannot answer about "making it up". Apparently, it depends on what to think about:)
For example, in some cases inventions like Point/2 really allow to make calculations with some given accuracy. However, it is better to use developers' recommendation, namely, once and for all (up to new documentation) to take as a rule using NormalizeDouble() function when calculating comparison operations.
It won't matter if you use NormalizeDouble(). And if you don't use it, it's a matter of luck.