Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: K Shen <kishshen@ya...>  20110307 01:22:32

Hi, I recently download a recent version of MinGWw64 crosscompiler (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 MinGWw64: 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 MinGWw64), and the difference from 8.0 (1.8e15) 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 MinGWw64  these functions are in the math library (libm), and I thought in crosscompiled 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 MinGWw64 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 Tietz <ktietz70@go...>  20110307 08:09:12

Hello Kish, 2011/3/7 K Shen <kishshen@...>: > Hi, > > I recently download a recent version of MinGWw64 crosscompiler (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 MinGWw64: > > 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 ‘‘dividebyzero’’ floatingpoint exception. — log(1) returns +0. — log(x) returns a NaN and raises the ‘‘invalid’’ floatingpoint exception for x < 0. — log(+oo) returns +oo We had here in our code checked for sign befor zerocheck. 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 MinGWw64), and the difference from 8.0 (1.8e15) seems to be about twice as large the expected precision. Hmm, here is rounding missing. This is a special case for noneodd x and noneodd 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 MinGWw64  these functions are in the math library (libm), and I thought in crosscompiled 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 MinGWw64 Yes, we changed some mathroutines to statisfy ISOC standard here. The MS routines aren't suiteable in all cases here. There is for example still an outstanding issue about the besselfunctions, which aren't satisfying ISOC 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 ISOC 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 branchmath. This implementation is slower, but in those cases more accurate. But also doesn't satisfy ISOC 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 
Sign up for the SourceForge newsletter:
No, thanks