2011/3/7 K Shen <[email protected]>: > > (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 meant y without decimal place and x without decimal place, which have for x ^ y always integer result. For x with decimal place and y without decimal place we can use here powi instead, which should do more exact rounding. >> 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?)? There are no compile-time flags for this. You would need to fallback to 1.0 runtime. >> Thanks and cheers, >> >> Kish >> >> >> >> > Regards, Kai ------------------------------------------------------------------------------ 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
