在 6/11/21 12:26 PM, sisyphus 写道:
My concern is that sin() is supposed to be returning a 53-bit precision value, and yet, for the given example, it arbitrarily returns a value that has precision of no more than 15 bits.
The extra precision is only significant if the result is supposed to be a floating-point number which is close to zero. If it is considered as a fixed-point number, truncated at the ~64th bit after zero, but stored in a floating-point format just because there is no fixed-point type, then there is no inconsistency.
If mingw is prepared to allow such behaviour, then one starts to wonder where else it might be occurring. Does it also happen with cos() ? Why would such behaviour be deemed acceptable for sin() but not for (say) the division operator ? It certainly makes me less confident about the general reliability of mingw's math operations.
I am pretty sure similar things happen for `cos()` when the argument is close to PI/2.Division is an instruction in hardware. If division is implemented with correct hardware instructions, then it is required to have no more round-off errors than ULP/2 (i.e. the result shall be unique).
This is the case on x64 where all of `float`, `double`, and `long double` is implemented via hardware. But we are too unfortunate on x86 unless SSE is enabled, as we set x87 to extended precision by default, so a `double` division is essentially a `long double` division whose result is rounded back to `double`, which may result in more round-off errors.
Our `sqrt()` and `fma()` may be inaccurate for some inputs as well.
The loss of accuracy itself with sin() annoys me a little - mainly because I'm seeing it as being unnecessary. (Perhaps I'm being unfair. Is it actually necessary ?) With the mpfr library, I can take the double 3.1415926535897931 and calculate the sine of that exact double value to 5000-bit precision. That value turns out to be 1.224646799147353177226...e-16 which agrees very nicely with the double precision figure of 1.2246467991473532e-16 that the gcc compiler comes up with.
MPFR is a professional math library and it is its obligation to guarantee such high precision, even if such an operation may be slow and unacceptable under some circumstances (e.g. video games).
I'm not going to get too excited over this, but having this current implementation of the sin() function strikes me as being a bit amateurish and rather unimpressive. Anyway ... please let me know if I should file a bug report about this, and I shall oblige.
I think you should. It's unlikely that people would agree on a solution, but that doesn't matter. -- Best regards, Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
