[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