My comments don't seem to be making it into the thread this week, possibly because of a switch between my reply-to email address and another. So, if it gets lost, perhaps nightstrike can intervene, or echo the information. Perhaps not.
The sqrt() function can be implemented with excellent speed to within a bit of full mantissa accuracy using iterations of Newton's method, as is classically done in libraries. Not so with ln() or exp(), which are classically done by extracting the exponent and using the reduced-range mantissa in a modified Chebychev approximation. Arithmetic co-processors do sqrt(), ln(), and exp() internally with 80-bit floating point, then store in 32, 64, or 80 bit floating point format. So, the co-processors can get full mantissa accuracy with 32-bit and 64-bit sqrt() and pow(x,0.5). So, the problem is non-existent for Intel/PPC and most other common workstation processors. Yet we are looking at software transcendental function libraries. James K Beard -----Original Message----- From: Greg Chicares [mailto:[email protected]] Sent: Friday, April 29, 2011 7:38 PM To: MinGW Users List Cc: mingw64 Subject: Re: [Mingw-w64-public] [Mingw-users] Math library discrepancies that surprised me. On 2011-04-29 19:55Z, K. Frank wrote: > > By the way, could someone confirm that mingw does use msvcrt for > sqrt and pow? http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot= src Looks to me like sqrt(double) calls into msvcrt. But pow() is a different story. Danny implemented it in libmingwex because of some quality-of-implementation problem with msvcrt; then people complained that the libmingwex version was slower, and I can't remember where it wound up, but it's all in the archives. > sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required > to by IEEE-754). If they should give exactly the same result always, then the first thing that needs to be fixed is any standard that allows them to differ. The language standards are so much looser than the numerical standard, even now, that I'd rather see C and C++ catch up to IEEE-754-1985 before asking them to go beyond. > Browsing some gcc lists, I did see some comments that suggest that > gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would > make sqrt and pow consistent (whether or not technically correct). Not so many years ago (perhaps when msvcrt was written), it was thought that correctly-rounded transcendental functions weren't feasible in practice, so library authors had a looser attitude toward exactness. If you have an ideal implementation of sqrt() but a pow() that's only approximate, should you special-case the power of exactly 0.5? If you do, then pow() and sqrt() will be consistent, but then the powers x^(0.5*(1-epsilon)) x^(0.5 ) x^(0.5*(1+epsilon)) might not be monotone. Some would call that a bad tradeoff. ---------------------------------------------------------------------------- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
