Problems in calculation of floating-point number accuracy

When we save the floating-point number and then read the floating-point number, the result may be a little bit biased. For example: float ft1 = 20.2; (This will cause the compiler to report a warning because the decimal point defaults to Double) CString str;str. Format (_t ("%f"), FT1), when the value of FT1 is equal to 20.200001. float ft2 = 20.8; CString Str;str. Format (_t ("%f"), ft2), when the value of FT1 is equal to 20.799999. Workaround 1: Use float instead of double storage: double dt1 = 20.2; Workaround 2: Use the%g format to remove the number of significant digits after 0. float ft1 = 20.2; CString Str;str. Format (_t ("%g"), FT1), when the value of FT1 is equal to 20.2. But can no longer use 0 alignment, hey hey hehe ... Solution 3: Use%0.4 to format float ft1 = 20.2; CString Str;str. Format (_t ("%0.4f"), FT1), when the value of FT1 is equal to 20.2000. There are some more complex, such as the loss of precision in the calculation process. Such as

Let's experiment with simple code:

int newwidth, newheight; Getthumbnailsize (n, A, newwidth, out newheight); Console.WriteLine ("{0}, {1}", Newwidth, Newheight); Getthumbnailsize (+, +, +,-newwidth, out newheight); Console.WriteLine ("{0}, {1}", Newwidth, Newheight);

The resulting results are:

100, 10099, 100

The first result is naturally not a problem, but why is 99 instead of 100 in the second result? To do this, we'll look at the following code:

Ratio:0.3333333333333333333333333333new value:99.99999999999999999999999999to int:99

As can be seen, although the use of decimal, the accuracy is very high, but after a divide, it has not recovered to the most accurate value. Although it has been said to pay attention to the accuracy of floating point calculation, but for this problem many friends often just understand that "can not directly two floating-point number equal", including my own first impression. But in fact, from the above results can also be seen, a floating point directly to the shape, it is the use of "tail" instead of "rounding" method. Therefore, although the value of NewValue is very close to 100, it becomes 99 after forcing the tail.

If you want to change the problem in the original way, the simplest approach might be to replace the final forced transformation with the Math.Round method. The Math.Round method uses rounding and should be able to solve the problem. But if that's the case, we'll think about how to be as precise as possible.

Dividing two floating-point numbers may lose precision, but in the case of multiplication, the accuracy is not lost in general, unless there is an overflow or too many decimal digits. Therefore, in order to maintain accuracy in the calculation process, we should do as much as possible multiplication, rather than division. For example, the following judgments:

if (decimal) Desiredwidth/originalwidth < (decimal) desiredheight/originalheight)

It is better to rewrite the multiplication operation as "equivalent".

Problems in calculation of floating-point number accuracy