在 2022/6/13 13:06, [email protected] 写道:
Again, this is correct mathematically. However, the value of (1 / 3) is in fact 
0.333333...

Computer cannot represent the value of '1 / 3' precisely in computer memory under IEEE 754 because of limited size of data type.

This function yield a imprecise value in the very first step, and the imprecision problem will mostly be enlarged in the future calculation.



This barely *sounds* plausible. But, the imprecision is not 'mostly enlarged'; it just happens to be there.

In your example, multiplying `1/3` in a loop eventually results in 
multiplication of `1/27` and `1/9`:

                  .097b425ed097b4    | exact value of 1/27, in C99 hex format
  *)              .1c71c71c71c71c    | exact value of 1/9, ditto
  -----------------------------------+----------------------------------------
     .10db20a88f469511e8d2b3183b0    | exact product
     .10db20a88f4695                 | exact product, rounded DOWN
                                     |
     .10db20a88f469598c1d7f7926fabc  | exact value of 1/243
     .10db20a88f4696                 | exact value, rounded UP


This illustrates how the result of `pow(3, -5)` is off from the rounded exact value by 1 ULP, and I believe this _should_ the eventual cause of the error that you have shown. Unfortunately, it is not easy to solve as it happens quite randomly; the proposed patch may work for you, while may break others.


I am putting this on hold for a while, until I have some time to look into it.


--
Best regards,
LIU Hao

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to