On Fri, Jun 11, 2021 at 1:22 AM LRN <lrn1...@gmail.com> wrote: > On 10.06.2021 10:03, Liu Hao wrote: > [snip] > > Before doing that, I would like to ask, does the inaccuracy really > matter? > > I always assumed that when dealing with floating-point math there's no > such > thing as "yielding precisely this number". You get something that is > accurate > to a certain point. If an implementation gives you something that is less > accurate than other implementations, that's not good, but shouldn't have > much > influence on your calculations. > > Why is this suddenly a concern? > > 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.
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. 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. 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. Cheers, Rob _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
