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

New comment
 
SK. писал (а):

I said so in the sense of a more-or-less comparison:

if (NormalizeDouble(x,Digits) > NormalizeDouble(y,Digits))

meaning that view constructions do not always work:

double a = NormalizeDouble(x,Digits);
double b = NormalizeDouble(y,Digits);
 
if (a > b)
  {
  ...
  }
I think the first and second have the same result.
The results assigned to variables a and b are normalized and then they can be compared, nothing will happen to them.
Renat wrote about something else, because in that example the result of subtraction of normalized values, in turn, is not normalized.
If you normalize the final result of an operation, you can assign it to a variable and further manipulate it. The main thing is that the variable itself should not change its value further on.
 
gravity001:
I didn't check for more or less, but I did check for equality.
I had comparison errors when I used this construction:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Why, don't you know?

What kind of errors?
 
Simca:
And to me the first and second in terms of the result ONE AND ONE.

This does work in some cases, but not always. This "not always" is dictated by the peculiar way in which values are stored in computer memory. That's just it.

The results assigned to the a and b variables are normalized and they can be compared further, nothing will happen to them.
You can't. That is, you can do whatever you want, but in order to get a guaranteed result, you should apply NormalizeDouble() directly in expression containing comparison operation.

Renat wrote about something else, because in his example the result of subtraction of normalized values is not normalized.
Yes. But that does not mean that your previous statements are correct.

If you normalize the final result of an operation, you can assign it to a variable and further manipulate it. The main thing is that the variable itself must not change its value further on.
 It can change its value in the last digit because of the specific computer technology in use. This can and does happen without the user noticing it. That is the point. In some cases it will work (for example, during debugging of a program), but when using this program it will often work as expected by the hapless programmer and sometimes it won't work.

 

My sincere condolences to the developers who have to explain the same thing 1000 times to every new user.

 
SK. писал (а):
gravity001:
I didn't check this construction for more or less, but I did check for equality.
I had comparison errors when I used this construction:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Why, don't you know?

What kind of mistakes?
The condition is not fulfilled, i.e. the equality is not fulfilled?
Also, why do you think the error is in storing or reading variables double from memory? Maybe an error in arithmetic operations?

Do you think there can be no error in such a case?

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?
 
gravity001 писал (а):
На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял.
У меня были ошибки при сравнении, когда я использовал такую конструкцию:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Почему, не знаете?

Please demonstrate this error!!!!
 
gravity001:
The condition is not fulfilled, i.e. equality is not fulfilled?
Also, why do you think the error is in storing or reading variables double from memory? Maybe an error in arithmetic operations?

Do you think there can't be an error in that case:

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?

I think the division operation itself is executed correctly.

The question under discussion is not about how to get the value of some variable (be it the value obtained by calculations or by initializing the variable), but about the fate of the value of that variable during program execution and even just computer operation. And its fate is unpredictable. Therefore, when programming logical operations, you should use the red-badgedNormalizeDouble() function.

To apply it is good. To apply it correctly is very good.

Not to use it is bad. Incorrect use - bad.

---

On holiday I want to...

 
SK. писал (а):
 It does work in some cases, but not always. This "not always" is dictated by the peculiar ways of storing values in computer memory. That's just it.
I know about ways of storing values in computer memory. :) I have about 20 years of programming experience. I even taught programming to university students in the past.

The results assigned to the a and b variables are normalized and they can be compared further, nothing will happen to them.
You can't. So, you can do whatever you want, but to get a guaranteed result, you should apply NormalizeDouble() right in the expression containing the comparison operation.

Naturally, before you can compare the result of calculating an expression with anything, you have to normalise it! Who can argue with that?! But it's irrelevant to our argument. I was speaking about the code's identity. The difference is that in the second case, the results of normalization are stored in variables. AND THAT'S IT!

That is, you claim that NormalizeDouble function has a result with a bit size higher than double (the result of this function occupies at least one bit of memory). For only this I can explain any loss (or change) when storing function's result in a variable. Or, when assigning, some tricky operation is performed, not simple byte-by-by-byte duplication of data from one memory location to another.

Once again I am not discussing correctness of separate normalizations of the right and left operands of the comparison operation or anything else. I am only questioning whether the results of the two code fragments above are identical.

If you normalize the result of an operation, you may assign it to a variable and operate on it further. The main thing is that the variable itself should not change its value further on.
 It may change its value in the last digit because of the specific computer technology used. This can and does happen without the user noticing it. That is the point. In some cases it will work (for example, during debugging of a program), and when using this program it will often work as expected by the hapless programmer, and sometimes it won't work.

WOW! And what kind of "specific computer technology" do you mean? Many things "go unnoticed" for user, but we are, after all,programmers. :) Nothing should go unnoticed for us, otherwise it will be not a computer but a generator of unpredictable results. :) Or maybe our computer has already got some errant bits? One day it reads this way, the next... One more time! In arithmetic operations with real numbers the result is indeednot absolutely exact (it has to do with the way real numbers are represented). But this does not apply to assignment operations. Once the NormalizeDouble function has worked and returned a result of type double, this result is placed into a variable simply by copying the value (all bytes will be matched). Further, while the variable value remains unchanged (i.e. it's only readable, but nothing is written into it), it's preserved in its original form and there are no signs floating around in any place. Read it and you'll get the same thing. But if you just multiply it by 1 and write the result back, nothing is guaranteed.

 
SK. писал (а):

My sincere condolences to the developers who have toexplain the same thing1000 times to every new user.

That's a blatant attack - I think I'll ignore it. :)
 
gravity001:

You think there can be no mistake in such a case:

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?

In this case, the result of the operation would be APPLICABLE 2.0
An error in very far digits may well be due to the way real numbers are represented.
1234567891011
New comment