From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2005-04-07 09:30:34
Somewhere in the E.U., le 07/04/2005
In article <001101c53a90$8591e580$ec4c0e52_at_fuji>,
"John Maddock" <john_at_[hidden]> wrote:
> >> log1p:
> >> ~~~~
> >> This algorithm is part of C99, but by no means all compilers support it
> >> yet,
> >> I used a Taylor series expansion for small x: I'm aware that there are
> >> much
> >> more efficient methods, but optimizing compilers completely trash the
> >> logic
> >> of these (Intel C++ proved to be particularly bad).
> > I had planed to work on it (and a few related such as expm1...)
> > something liketwo years ago and had planed to add it to the same special
> > functions library. They really are important.
> Agreed: how were you planning to implement expm1? The obvious series
> expm1(z) = SUM[k=1, INF] (z^k / k!)
> would converge in less than B steps for a B bit floating point type and |z|
> < 0.5 (in other words reasonable but not astounding performance), in fact it
> would be trivial to plug that into my existing series summation code.
> Alternatively there's a table based method
> (http://portal.acm.org/citation.cfm?doid=146847.146928) which claims to be
> particularly accurate.
I do not have institutional free access from my "beloved
> Any others? You've got my curiosity roused...
In the stopgap series of implementations that my "special
functions library" is, I would have simply used a succession of
truncated series expansion, at least near zero (like I did for the
various other functions), and then rely on whatever exponential function
was coded in the user's platform's standard library.
Of course, one can only dream of writing a C++ implementation of
NIST's DLMF (http://dlmf.nist.gov/), ready any decade now... (OK,
officially this year...).
On a related point, I recently discovered that, at least for the
Sun platform where tests are carried out for Boost, "long double" has
numeric limits set correctly (and with values different than those of
"double"), but some standard library functions (such as the exponential,
apparently) have no "long double" overload, and seemingly truncate to
"double". I have to adapt my test to declare the library to pass (rather
than fail, such as is now the case), with warnings of QOI. This problem
might bite your implementation as well, and IMHO does militate for the
above dream to come true!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk