lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] MinGW-w64 roundl() anomaly


From: Vadim Zeitlin
Subject: Re: [lmi] MinGW-w64 roundl() anomaly
Date: Fri, 16 Dec 2016 14:37:39 +0100

On Fri, 16 Dec 2016 05:23:25 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-12-16 01:39, Vadim Zeitlin wrote:
...
GC> >  I also checked that the problem still happened with the latest MinGW-w64
GC> > version (6.2.0) and that it only happened with "long double" and roundl()
GC> [...]
GC> >  Looking at its source code:
GC> > 
GC> > 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/math/roundl.c
GC> 
GC> A one-character change to that URL gives their round() and roundf()
GC> implementations, which are essentially the same. I think there's a good
GC> chance that their round() would fail for some argument; maybe roundf()
GC> would also.

 I'm not sure, I thought that perhaps the extra (96 bit) precision used
internally might make the comparison "ceil(x) - x > 0.5" pass in this case.
At any rate, the same program using either "double" or "float" gives almost
the expected results:

Using FE_DOWNWARD   rounding mode round(0.49999999999999994449) = 
-0.00000000000000000000
Using FE_TONEAREST  rounding mode round(0.49999999999999994449) = 
0.00000000000000000000
Using FE_TOWARDZERO rounding mode round(0.49999999999999994449) = 
0.00000000000000000000
Using FE_UPWARD     rounding mode round(0.49999999999999994449) = 
0.00000000000000000000

(I say "almost" because getting a negative zero is still unexpected).

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]