|
Boost : |
From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-04-24 05:39:32
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:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]
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: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On 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" <boost_at_[hidden]> 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
|
|
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk