Errors, bugs, questions - page 2360

[Vladimir Pastushak]

Aliaksandr Hryshyn:

Error for developers.

The script does not compile, identify why))). Use attached file.

Same file:

All compiles, remove Error line

[Fast235]

Vladimir Pastushak:

Everything compiles, delete line Error

line length limitation in the editor

[Aliaksandr Hryshyn]

Fast528:

Limiting the length of a line in the editor

A string is not displayed when it becomes longer than 4095 characters.

[A100]

fxsaber:

Please explain to a fool why this is the case here?

Suppose we can only operate on odd numbers, and if the result of an arithmetic operation becomes an even number, it is assumed to be the nearest odd number above, then

(43 -  5) - 7  = (38)39 - 7  = (32)33
 43 - (5  + 7) = 43 - (12)13 = (30)31 

33 != 31

[Ilya Malev]

fxsaber:
I spent several hours on searching for divergences. I found this

The peculiarities double know, but not such that if you change the order of addition (except for the relatively very different numbers), the result is different! Please explain to a fool why this happens here?

You only need to look at the bottom two lines in the source.

As you yourself like to say, the agolithm that is laid down for the accuracy of rounding double to the same number at the limit of the specified accuracy is "crooked". The reason, obviously, is that the same value obtained by different methods (swapping multipliers, opening parentheses, etc.) in double representation can turn out to be different numbers, maximally close to the desired one from different sides. Round up to the next digit, and then you decide how to deal with the last one...

[pavlick_]

fxsaber:

When you do size+point, you overflow the mantissa followed by rounding/rejection (depending on fpu mode.

   float avg = 0.7;
   float size = 0.3;
   float point = 0.4;

   float r1 = avg - size - point;
   float r2 = avg - (size + point);
   cout << "r1 == r2 ? " << (r1 == r2) << '\n';

   cout << "-----avg-----\n";  prfl(avg);
   cout << "-----size-----\n"; prfl(size);
   cout << "-----point-----\n"; prfl(point);
   cout << "-----avg - size------\n"; prfl(avg - size);
   cout << "-----(avg - size) - point------\n"; prfl((avg - size) - point);
   cout << "-----size + point------\n"; prfl(size + point);
   cout << "-----avg - (size + point)------\n"; prfl(avg - (size + point));

r1 == r2 ? 0
-----avg-----
implicit_1 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
exponenta = -1
sign = 0
-----size-----
implicit_1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
exponenta = -2
sign = 0
-----point-----
implicit_1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1
exponenta = -2
sign = 0
-----avg - size------
implicit_1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0
exponenta = -2
sign = 0
-----(avg - size) - point------
implicit_1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
exponenta = -25
sign = 1
-----size + point------
implicit_1 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 0
exponenta = -1
sign = 0
-----avg - (size + point)------
implicit_1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
exponenta = -24
sign = 1

In general, the result of two doublets will be the same only if they are obtained in the same way (unless you count cases where we are dealing with integers).

[fxsaber]

A100:

Ilya Malev:

pavlick_:

Thanks for the answers, each one was valuable. For the first time I encountered (noticed) that adding the same items to the PRICE, but in different sequence creates different PRICES. Hence different results in the Tester.

When discussing dubs, it was clear when and why they could be compared to each other. But the price plus points and different output result is the first time the TC result has been so clearly affected.

It turns out that to avoid these ambiguities, we need to add a mizzen less than half a point to the calculated price, and then normalise.

[Ilya Malev]

fxsaber:

It turns out that in order to avoid these ambiguities, we need to add to the calculated price a mere fraction less than half a point, and then normalise.

And there is also an opinion that if the results of TC change a lot from such insignificant things, you should say "thank you" and throw such TC in the trash.

[Artyom Trishkin]

fxsaber:

Thanks for the replies, each one was valuable. First encountered (noticed) that adding the same items to a PRICE, but in a different sequence creates different PRICES. Hence different results in the Tester.

When discussing dubs, it was clear when and why they could be compared to each other. But the price plus points and different output result is the first time the TC result has been so clearly affected.

It turns out that to avoid these ambiguities, we need to add a mizzen less than half a point to the calculated price, and then normalise.

Maybe it is worth mapping in the features?

[fxsaber]

Ilya Malev:

And there is also the opinion that if the results of a TC change a lot from such small things, you should say "thank you" and throw such a TC in the trash.

They don't change much, they just change. That's enough to start an investigation.