Question to the MQL4 masters. Again about Double Compare. - page 10

New comment
 
Simca:
SK. wrote (a):

My sincere condolences to the developers, having toexplain the same thing1000 times to every new user...



This is already a blatant attack...
I agree. Although SK. is an authority on the forum, but "specific computer technology" makes me suspicious too.
It's written in textbooks about storing real numbers in memory and it doesn't say anything about variables changing by themselves. Although I've heard it not only from SK on this forum.
So if you have misled every new user 1000 times, you should now find them and apologize for your words!

I agree with Simca. When performing arithmetic operations errors are possible, but when storing, writing or reading they are excluded!

That's why I asked the NormalizeDouble() function algorithm, maybe it also has arithmetic operations that cause an error?
What do you think Simca?
 

OK. You say that so confidently that I'm beginning to doubt what I'm saying.

I used to work on an old PC with 256MB RAM until some time ago. When you google a few programs, the OS would dump some of the data to disk, and then load it up again. Since I modified the code (specifying normalization in comparison operator) the error stopped appearing. But I began to doubt after hearing your words - what if I actually hadn't noticed the error?

Now I don't know whether to apologize or not. If I am wrong, then let 1000 users forgive me.

(but still it's better to perform normalization directly when calculating the comparison operation:)

 
gravity001:
It's written in textbooks about storing real numbers in memory and it doesn't say anything about variables changing on their own. It's not justSK that I've heard this on this forum though.
Nothing by itself is changed during storage. But the way real numbers are represented in computer memory affects the accuracy (bit depth) of the stored values. When performing arithmetic operations on real numbers, the result is often "not accurate enough" (from a human point of view), so sometimes it is necessary to normalise the operation result. It is definitely necessary to normalize the result of operations in case of subsequent comparison to equality (often to >, <). It's also necessary to normalize the result if you operate with values with the required strictly set digit capacity (for example, prices). The intermediate calculations with real numbers usually do not require normalization.
But, all this concerns calculations while values stored in memory will not change regardless of whether they are normalized or not.
gravity001:
That's why I was asking the NormalizeDouble() function algorithm, maybe it also has arithmetic operations that cause an error?
What do you think Simca?
Well, about the algorithm of NormalizeDouble function we should ask the developers, and I am not one of them. :) Besides, it is not the subject of the dispute, because the NormalizeDouble function in both code fragments was used in an absolutely identical way. The only difference was in a direct comparison of results of the two normalizations and in writing these results into variables and then comparing their values. And I noticed that since the type of the value returned by the NormalizeDouble function coincides with the type of the variable used for storage, there would be no difference between the fragments cited. But if the NormalizeDouble function returns a value of larger dimension than the variable in which it is stored, then the difference might occur and we cannot be sure that it is identical. But according to MetaEditor's HELP the data type in both cases is double, so there should be no difference, regardless of how the NormalizeDouble function is implemented.
 
SK. писал (а):

(but still it is better to perform normalisation directly when calculating the comparison operation:)

And with this, as applied to each new user, I absolutely agree. If you don't have a clear idea of what and how it works, it's more reasonable to go by the safer and more reliable way! But it does not concern you and me. :)
And for my part (for those who do not fully understand the essence of the question) I can also recommend:

(but still, it is better to perform normalisation directly when calculating the comparison operation (c) SK.

 
SK. писал (а):

(but it is still better to do the normalisation directly when calculating the
the comparison operation is calculated:)





Sorry, but in terms of efficiency there are much better implementations for comparing data requiring normalisation. Basically, this is the standard (comparison algorithm). You have to compare the difference with half the scale dimension. What I mean: to compare prices (whether they are different or not) you should take the difference and compare it to 0.5*Roynt (it can be calculated only once during initialization of the EA/script/indicator. This is much more efficient than calling one function, and even more so if it's also in a loop) .... And it won't matter how this data is stored and to what insignificant sign it is rounded.

Good luck.
 
Firstly, working with dubles is purely a compiler thing, so to demand convenience from mql4, which is essentially a hidden intrinsic compiler, is unreasonable. The main thing, the developers have given a way to GUARANTEED the correct result of comparison, we checked it with our hands, it is, of course, graphical, but WORKABLE!!! Although the documentation says that normalize only in case of "!=" or "==", our independent and expert tests have shown that (a>b) DOES NOT WARRANT (!) correct result if a turns out to be equal to b! Even if you PREDVORITELY normalize both a and b, the result is unpredictable. And here is a construction from developers:: NormalizeDouble(a-b, Digits)>0 works reliably! I don't know why folks here don't like normalize function... Maybe it (internally) is quite sempotical done like this: two dables are divided by double precision, and rounded down (or up). Afterwards, the whole ones are compared without any problems.
 
.FG писал (а):
Firstly, working with dubles is purely a compiler thing, so to demand convenience from mql4, which is essentially a hidden intrinsic compiler, is unreasonable. The main thing, the developers have given a way to GUARANTEED the correct result of comparison, we checked it with our hands, it is, of course, graphical, but WORKING!!! Although the documentation says that normalize only in case of "!=" or "==", our independent and expert tests have shown that (a>b) DOES NOT WARRANT (!) correct result if a turns out to be equal to b! Even if you PREDVORITELY normalize both a and b, the result is unpredictable. And here is a construction from developers:: NormalizeDouble(a-b, Digits)>0 works reliably! I don't know why folks here don't like normalize function... Maybe it (internally) is quite sempotical done like this: two dables are divided by double precision, and rounded down (or up). And afterwards the integers are compared without any problems.

Please write in proper Russian.

 
Give me a link to the site of the developer (of the Russian language), and I promise that I will use the author's definitions ONLY. :) Your point, in my opinion, no more correct than mine, but if YOU PERSONALLY want to understand, then I'll do a "spokesman for Rosh", if you can not distinguish between blah-blah from expert opinion. Because I wrote not you, and the 1001st beginner. :)
 
.FG писал (а):
Give me a link to your site and I promise I'll ONLY use the AUTHOR'S DEFINITIONS. :) Your idea, I think, is not more correct than mine, but if YOU PERSONALLY want to understand, I'll do a "spokesman for Rosh", if you can not distinguish between blah-blah and expert appraisal. Because I was not writing to you, but to the 1001st newcomer. :)

For example www.gramota.ru

We do not have an albanian section of the forum. Nevertheless, after the next non-Russian post you will be sent there. Please, don't make it sound like you're using the language.

 
In that case you, stringo, should go to Cyril and Methodius with a Diploma of Achievement in Programming! All these problems with normalization I encountered in free DOS compilers, which have long been implemented conveniently in current versions. That's why some programmers don't understand why they need such an outdated check of doublings. When they rewrite their code, cramming everywhere normolysis compared to zero, they will be surprised to find absence of errors in their own "C-logic", and not RIGHT comment of fathers-executives, because they can piggyback on optimization and other secondary things. But questions concerning the RESULTS of basic calculations will remain crucial, requiring the paramount attention. And if you threaten to send me away again, we'll go to some CME, we'll take their documentation and write a program with FIXes and other tricks in OLBANIC. :) And you'll be out of work. You'll make your mq6 and you'll want someone to at least test your products in Albanian, but no, we won't be there... Because you banned us quietly yourself... :)))))))))))))))))))))))000
1...34567891011
New comment