I absolutely agree that they are to serve *practical* purposes, and
I would encourage any guide to accuracy that authors (and others) can provide. Some functions are easy - within a few eps over the whole domain. You say "LIA has already set framework for those things", but is it really suitable for 'more difficult' functions? But I would caution that, for some functions, there are even more PhDs of study of accuracy than in algorithms themselves. It would cost vendors more to provide comprehensive accuracy information than writing the functions. For a start, I have not found many really accurate reference values for some functions (A&S sometimes struggle to achieve float 32-bit). Many published algorithms provide almost no accuracy data. How do you specify accuracy (never mind speed and size)? Stephen Moshier in his collection provides a mean and max from thousands of random arguments, which is certainly useful, but may mislead - like sincos near to multiples of pi. So there is some danger of starting the equivalent of processor chip 'benchmark wars'. For many practical statistical purposes, 32-bit float accuracy will suffice. Do you need to know that the probability of two means being different is 0.95475869798765823? Often one just decides if it is > 0.95. And the probability probably has a 95% confidence interval of 0.9 to 0.97 anyway! So, for me, the most important thing is to have some implementation for people to put to practical use, while others work on improvements and descriptions of accuracy. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Example of accuracy data from Cephes incomplete beta - good - but shows how complicated it is! * ACCURACY: * Tested at uniformly distributed random points (a,b,x) with a and b * in "domain" and x between 0 and 1. * Relative error * arithmetic domain # trials peak rms * IEEE 0,5 10000 6.9e-15 4.5e-16 * IEEE 0,85 250000 2.2e-13 1.7e-14 * IEEE 0,1000 30000 5.3e-12 6.3e-13 * IEEE 0,10000 250000 9.3e-11 7.1e-12 * IEEE 0,100000 10000 8.7e-10 4.8e-11 * Outputs smaller than the IEEE gradual underflow threshold * were excluded from these statistics. | -----Original Message----- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Wednesday, April 23, 2003 9:15 PM | To: Boost mailing list | Subject: Re: [boost] C++ Standard Library proposal - Math | functionsforStatistics | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | | Indeed, I doubt if long double is practically useful for many applications - | | even 16 decimal place 64-bit double will be impracticable on MSVC | where there | | isn't really a long double (you may need to use 80-bit calculations to get a | | 64-bit accuracy result). | | | | But I don't believe that this is a problem - exp, sin etc don't | really work for | | long double on MSVC either! And many implementations are not fully | accurate - | | nor would one necessarily want to wait while they calculate to full | accuracy. | | | | The Standard does not, and should not, make any requirements about accuracy, | | memory size or speed. | | | | So I feel they are panicing a bit. | | Being one of the persons who raised the accuracy issue, I think I have | to say why. | | The proposed mathematical functions are not there just for selling | compilers. They are there to serve *practical* purposes. If there is | no accuracy guarantee, they don't worth to have -- they are already so | specialized. LIA has already set framework for those things. Any | serious proposal to include such specialized functions need to pay | attention to those things. | | -- Gaby | _______________________________________________ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost