Comparison and analysis of floating point numbers in asp.net

Examples are as follows: here, here and here. (They are all worth reading. Learning from others' mistakes is less painful than learning from yourself)
We will begin our solutions by presenting another simple example.

For (double r = 0.0; r <1e22; r + = 1.0) printf (".");

How many points will this program print? This time it's clear, isn't it? This termination condition is no longer equal to the test. This loop stops after 10 ^ 22 traversal. Or .. Yes?

It's really bad. Once again it's an endless loop. Why? Because when the value of r increases, the accuracy of this variable cannot be large enough to store the numbers in decimal places of all r. The last part will be lost. Therefore, when we add 1 after such a large number, the result is similar to the original number.

Exercise: try to judge the Maximum r value in our cycle. Check your answer. If your judgment fails, find out the cause.

After observing, we will show why the expression fabs (a-B) <eps tutorial ilon (using the fixed epsilon value, we recommend that you use 1e-7 to 1e-9) is not ideal for comparing double precision numbers.

The values are 123456123456.1234588623046875 and 123456123456.1234741210937500. There is nothing special about them. They are just two values that can be stored without the approximation. Their direct difference is about 2e-5.

Now let's look at the bitwise form of these two values:

First: 01000010 00111100 10111110 10001110 11110010 01000000 00011111 10011011
Second: 01000010 00111100 10111110 10001110 11110010 01000000 00011111
Yes, that's right. This is two consecutive values that can be stored in double. Any errors obtained by using an approximation can convert one of the two into another (or more than one ). But they are still different, so our original test "equal" cannot work.

What we really need is to tolerate small precision errors. As we can see, double can store a maximum of 15 10-digit numbers. The last number will be lost due to an error in precision accumulated through approximation. But how should we tolerate these errors?

Instead of using a fixed constant & epsilon;, we use a value related to the number of orders of magnitude of comparison. More specifically, if x is a double-precision number, then x * 1e-10 is a 10-fold value smaller than x. Its maximum valid bits correspond to the maximum valid bits of x's 11th bits. This allows it to meet our needs well.

In other words, a better way to compare a and B is to check whether a is between B * (1-1e-10) and B * (1 + 1e-10. (Be careful. If B is a negative number, the first of the two numbers will be larger !)

Have you seen the problem with this comparison method? Try to compare 1e-1072 and-1e1072. Both numbers are equal and equal to 0, but our test will fail when dealing with this situation. This is why we both need to perform the first Test (absolute test error) and the second Test (test relative error ).

This is the method that tc uses to check whether your return value is correct. Now you know why.

There are better comparison functions (see one of the references), but more importantly, you need to know that in practice, you often just use absolute error testing and are lucky to succeed. Why?
Because all the numbers included in the calculation are within a limited range. For example, if the maximum number to be compared is only 9947, you know that a double can store an additional 11 digits after the decimal point. Therefore, we use epsilon = 1e-8 for absolute error testing, and we discard the last three digits.

The advantage of this method is clear: the absolute error check is simpler than the above advanced test.

Elections (a div2 easy with a success rate of only 57.58%)
Archimedes
Sortestimate (the binary search is quite tricky to get right if you don't understand precision issues)
Perforatedsheet (beware, huge rounding errors possible)
Watchtower
Packingshapes