## Re: [Mingw-users] [Mingw-w64-public] Math library discrepancies that surprised me.

 Re: [Mingw-users] [Mingw-w64-public] Math library discrepancies that surprised me. From: JonY - 2011-05-01 13:48:59 Attachments: signature.asc 0xED74C077.asc ```On 5/1/2011 19:01, Peter Rockett wrote: > On 01/05/11 08:43, Keith Marshall wrote: >> On 30/04/11 23:14, Kai Tietz wrote: >>> long double (80-bit): >>> digits for mantissa:64 >>> digit:18, min exp:-16381 (-4931 10th) >>> max exp: 16384 (4932 10th) >>> Epsilon:1.0842e-019 >>> >>> Which means that indeed the accuracy of 20 digits after decimal point >>> are pretty precise here. > > I've followed with some unease at the way "accuracy" and "precision" > have been used in this thread. To nuance Keith's point below, you can > write down 20 digits after the decimal point but that does not mean you > have 20-digit accuracy. They are very different things. > >> You cannot get 20 decimal digits precision after the decimal point, with >> 80-bit floating point. You cannot even get 20 significant digit >> precision -- there is a subtle but extremely important distinction. The >> best you can hope for is 19 significant digits. > > So long doubles don't do normalisation, and thus have no extra, implicit > mantissa bit? (Have come across something that suggests this as an > historical quirk but it was unclear.) That would set long doubles apart > from singles and doubles in the IEEE754 scheme of things... Interesting. > > To add my two pennyworth on pow/sqrt: Although changing the behaviour of > pow() to give the same answer as sqrt() for the special case of 0.5 may > seem like a good idea, this is potentially introducing a discontinuity > into pow() which could be disastrous. Fundamentally, why should you > expect two transcendental quantities calculated in different ways with > finite-precision arithmetic to give exactly the same result? Floats are > not real numbers! In fact some of the comparisons in this thread have > involved differences of a few ulps (units of least precision) - which > looks really good to me. Good point, does only 0.5 get special treatment? What of 0.25 or 0.499....? I think those concerned with accuracy and precision over performance should be using something more specialized like GMP/MPFR arbitrary precision libraries, with the C library (libmingwex in this case) providing a "good enough" and "fast enough" implementation. Slightly OT: Arbitrary precision square root: ; ```

## Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks