# Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

## 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: Peter Rockett - 2011-05-01 11:01:13 ```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. > Alas, this sort of mathematical ineptitude seems to be all too common > amongst the programming fraternity. It isn't helped by a flaw in the > gdtoa implementation common on BSD and GNU/Linux, (and also adopted by > Danny into mingwrt); it fails to implement the Steele and White stop > condition correctly, continuing to spew out garbage beyond the last bit > of available precision, creating an illusion of better accuracy than is > really achievable. Can't answer for the gdtoa implementation but surely this is only a problem if you're naive enough to actually believe all the digits! If your algorithm relies on getting accuracy down to the ulp level for transcendentals then you really should be googling "ill-conditioning". P. ```