(I don't think I cc'ed this to the list, so I am forwarding this. Apologies if this appear twice)
--- On Mon, 7/3/11, K Shen <[email protected]> wrote: > From: K Shen <[email protected]> > Subject: Re: [Mingw-w64-public] problem with pow() and log() > To: "Kai Tietz" <[email protected]> > Date: Monday, 7 March, 2011, 16:15 > Hi Kai, > > Thank you very much for your quick reply! > > --- On Mon, 7/3/11, Kai Tietz <[email protected]> > wrote: > > > > > 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 > > :) > > > > Do you mean odd y >= 0? [y = 3 in my example] > > I have now tried more values with the power function, and > it seems that for even x, then I seem to get a non-integral > values for any integeral values of y >= 2 (I did not try > y = 1). > > I found this precision problem because in our system > (ECLiPSe consraint logic programming language), we have a > number type "bounded reals", which has an upper and lower > bound, and the bounds are supposed to enclose the exact > value of the real number (which might not be representable > with finite precision). We obtain this from a double value > by rounding it up and down, and using these as the bounds. > In the case of the result of > power(2.0, 3), the upper bound is still less than 8.0 after > rounding up. > [and is the same value as the lower bound on other > platforms, which is why I knew it was about two times off > the expected precision] > > > > 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. > > > > Thanks for the explanation. Are there anything else done > by > MinGW-w64 other than the floating point functions? > > > > > 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. > > > > Do I need to compile w64-MinGW in order to get this, or can > I specify this with a flag (for the compiler or linker?)? > > Thanks and cheers, > > Kish > > > > ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
