On Wed, Jul 25, 2012 at 07:33:07PM +0200, Rainer Hurling wrote: > On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote: > > > >If you actually want to test expl() to see if it is producing > >a decent result, you need a reference solution that contains > >a higher precision. I use mpfr with 256 bits of precision. > > > >troutmask:fvwm:kargl[213] ./testl -V 2 > >ULP = 0.3863 > > x = 2.000000000000000000e+00 > >libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 > >mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 > >mpfr: 7.3890560989306502272304274605750078131803155705518\ > > 47324087127822522573796079054e+00 > >mpfr: > >0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 > > > >The 1st 'mpfr:' line is produced after converting the results > >fof mpfr_exp() to long double. The 2nd 'mpfr:' line is > >produced by mpfr_printf() where the number of printed > >digits depends on the 256-bit precision. The last 'mpfr:' > >line is mpfr_printf()'s hex formatting. Unfortunately, it > >does not normalize the hex representation to start with > >'0x1.', which makes comparison somewhat difficult. > > > > Many thanks also for this mpfr example. This helps me to understand a > little bit more what is going here. So on amd64 even the expl() result > is far from what mpfr provides. Of course!. MPFR is a multiple precision library. One specifies the precision, and mpfr returns a value with that precision. #include <mpfr.h> int main(void) { int i, j[5] = {24, 53, 64, 113, 256}; mpfr_t x, f; for (i = 0; i < 5; i++) { /* Set working precision to j[i]. */ mpfr_inits2(j[i], x, f, MPFR_RNDN); mpfr_set_ui(x, 2, MPFR_RNDN); mpfr_exp(f, x, MPFR_RNDN); mpfr_printf("exp(%Re) = %Re\n", x, f); mpfr_clears(x, f, NULL); } } troutmask:fvwm:kargl[222] cc -o z -I/usr/local/include a.c -L/usr/local/lib\ -lmpfr -lgmp troutmask:fvwm:kargl[223] ./z exp(2e+00) = 7.38905621e+00 exp(2e+00) = 7.3890560989306504e+00 exp(2e+00) = 7.3890560989306502274e+00 exp(2e+00) = 7.38905609893065022723042746057500802e+00 exp(2e+00) = 7.38905609893065022723042746057500781\ 3180315570551847324087127822522573796079054e+00 -- SteveReceived on Wed Jul 25 2012 - 15:53:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC