From: K S. <kis...@ya...> - 2011-03-07 01:22:32
|
Hi, I recently download a recent version of MinGW-w64 cross-compiler (compile for 64 bit Windows on Linux), to replace a old version I have been using for about two years. I have found two problems that didn't occur with the old version of MinGW-w64: 1) log(-0.0) now returns NaN, instead of -infinity (log(0.0) does return -infinity). I think the standard behaviour is to return -infinity. Our code (which runs on many platforms) seems to rely on this. In most man pages, the exact behaviour for -0.0 is not always specified, but it is for Mac OS X, and there it is specified to return -inifity. 2) pow(2.0, 3) now returns 7.9999999999999982 instead of 8.0. While this is close to 8.0, on all other platforms we get 8.0 (and also from the previous version of MinGW-w64), and the difference from 8.0 (1.8e-15) seems to be about twice as large the expected precision. I was also surprised that the bheaviour is different between the old and recent versions of MinGW-w64 -- these functions are in the math library (libm), and I thought in cross-compiled MinGW, all standard C functions are supplied by the native Microsoft libraries, so there should not be any difference in behaviours between different versions of MinGW-w64 Any suggestion on how the problems can be fixed, and are these functions defined in MinGW or are the Microsoft versions used? If the Microsoft versions are used, why is there this difference? Thanks in advance for any information and help! Kish Shen |
From: Kai T. <kti...@go...> - 2011-03-07 08:09:12
|
Hello Kish, 2011/3/7 K Shen <kis...@ya...>: > Hi, > > I recently download a recent version of MinGW-w64 cross-compiler (compile for 64 bit Windows on Linux), to replace a old version I have been using > for about two years. > > I have found two problems that didn't occur with the old version of MinGW-w64: > > 1) log(-0.0) now returns NaN, instead of -infinity (log(0.0) does return -infinity). > > I think the standard behaviour is to return -infinity. Our code (which runs on many platforms) seems to rely on this. In most man pages, the exact behaviour for -0.0 is not always specified, but it is for Mac OS X, and there it is specified to return -inifity. Yes, thanks for noticing that. Sepcification says (ISO/IEC 9899:TC3) F.9.3.7 The log functions 1 — log(±0) returns -oo and raises the ‘‘divide-by-zero’’ floating-point exception. — log(1) returns +0. — log(x) returns a NaN and raises the ‘‘invalid’’ floating-point exception for x < 0. — log(+oo) returns +oo We had here in our code checked for sign befor zero-check. I fixed that at rev 4066. > 2) pow(2.0, 3) now returns 7.9999999999999982 instead of 8.0. While this > is close to 8.0, on all other platforms we get 8.0 (and also from the previous version of MinGW-w64), and the difference from 8.0 (1.8e-15) seems to be about twice as large the expected precision. Hmm, here is rounding missing. This is a special case for none-odd x and none-odd y >= 0. So we need to extend here our routine. I will think about that, but of course are patches for fixing it welcome, too :) > I was also surprised that the bheaviour is different between the old > and recent versions of MinGW-w64 -- these functions are in the math library (libm), and I thought in cross-compiled MinGW, all standard > C functions are supplied by the native Microsoft libraries, so there should not be any difference in behaviours between different versions of MinGW-w64 Yes, we changed some math-routines to statisfy ISO-C standard here. The MS routines aren't suiteable in all cases here. There is for example still an outstanding issue about the bessel-functions, which aren't satisfying ISO-C in all cases. Those routines are implemented in older runtime via gdtoa implementation, which sadly has proven as pretty slow for IEEE operations and additional had shown some issues about ISO-C standard, too. > Any suggestion on how the problems can be fixed, and are these functions defined in MinGW or are the Microsoft versions used? If the Microsoft versions are used, why is there this difference? Well, first you can fallback to 1.0 branch-math. This implementation is slower, but in those cases more accurate. But also doesn't satisfy ISO-C standard well. Second way to fix that (and IMHO the better one) spent some effort in current implementation to improve it. > Thanks in advance for any information and help! > > Kish Shen Regards, Kai |