[boost] Re: [Ann] Proposed Math library additions (complex numberinverse trig functions).

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2005-04-07 09:30:34

Somewhere in the E.U., le 07/04/2005

   Bonjour

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 
> expansion:
> 
> 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 
workplace" (grumble...).

> Any others? You've got my curiosity roused...
> 
> John.

      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!

         Hubert