Re[2]: [lmi] confused by latest expm1.c changes

[Vadim Zeitlin]

On Mon, 23 Jun 2008 12:17:24 +0000 Greg Chicares <address@hidden> wrote:

GC> However, consider:
GC> 
GC> 
http://www.boost.org/doc/libs/1_34_1/doc/html/boost_math/math_special_functions.html#boost_math.math_special_functions.expm1
GC> 
http://www.boost.org/doc/libs/1_34_1/doc/html/boost_math/math_special_functions.html#boost_math.math_special_functions.log1p
GC> 
GC> Is that the answer?

 Probably. I don't know what exactly are the accuracy guarantees of Boost
implementation of these functions but I think we can be sure that it's
better than 

            double expm1l(double x) {return exp(x) - 1.0;}

which would make any numeric programmer cry out with disgust.

 One problem with using these Boost function is that they're new since
1.34 and LMI uses 1.33. OTOH maybe it's time to update to Boost 1.35
anyhow?

GC> I would hope that we could expunge 'expm1.c' and just use boost's
GC> alternative. Now that would be a very welcome change if you have time
GC> for it.

 I can do it but it would be nice if you could still apply the patch I sent
in the meanwhile. It certainly doesn't solve the big problem but it does
restore the code to its state before the latest changes to expm1.c so that
it at least compiles. Basically I just want my MSVC compilation patch to be
as small possible to increase the chances of it being reviewed and accepted
quickly so it would be nice if any not really MSVC-specific patches could
be dealt with independently.

GC> I have deliberately called these functions only in
GC> 'math_functors*.?pp', so a local solution there would be fine. For
GC> MinGW, I would hope that the libmingwex implementations (cvs citations
GC> above) are faster, and that the same could be said of gcc with glibc;
GC> as long as that's true, we'd want to use native implementations where
GC> available, and boost only where we must.

 Boost functions use the standard ones if BOOST_HAS_{EXP1M,LOG1P} is
defined. I'm not sure if it's auto-detected correctly for mingw32 (it
should be auto-detected under Linux from looking at the code) but in the
worst case we can predefine it ourselves.

 Regards,
VZ