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

[Greg Chicares]

On 2008-06-22 22:24Z, Vadim Zeitlin wrote:
> 
>  I'm a bit confused by the latest change to expm1.c:
> 
>     http://cvs.savannah.gnu.org/viewvc/lmi/expm1.c?root=lmi&r1=1.8&r2=1.9
> 
> The commit message simply says "Prevent type issues diagnosed by gcc-4" but

On 20080620T1314Z I changed some other files substantially. One
incidental effect was renaming the conditional macros; that was
the only effect on this file, and it's only incidentally related
to gcc-4 or type issues.

> this check in changed the conditions in expm1.c without changing the names
> of the functions themselves which seems wrong to me: shouldn't we define
> expm1l() and not expm1() inside a !LMI_COMPILER_PROVIDES_EXPM1L test?

Yes. I was aware of the issue, but deferred it so I could work
on other things instead. I figured that every decent compiler
provides expm1l() and log1pl() these days, so that this would
only affect comeau with the antique version of MinGW gcc it
supports--so I didn't bother noting it because I didn't think
it'd be a problem for you. However, even if that's the case,
you're always welcome to review whatever I do and comment on it;
and even more welcome to fix whatever I do wrong--and there's
a lot wrong with this file.

>  If I'm right, the following patch needs to be applied:

Let me start with a small question first. For the function
that's written with inline asm, did you just change the types,
or did you replace double with long-double code from the MinGW
repository? Here's the double version:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/expm1.c?cvsroot=src

and for long double it's

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/expm1l.c?cvsroot=src

There might be some implementation difference that could make it
incorrect just to change the types. Hmmm...yes, there is indeed;
you don't have to answer that question.

Oh, and, BTW, the __COMO__ conditionals are invalid. If you want
to see why, put an '#error' directive inside them and compile
with como using the lmi makefiles. [Before spending any time on
that, read on....] Furthermore, BTW, this:
  double expm1(double x) {return exp(x) - 1.0;}
isn't tolerable even for a secondary platform; I wrote it, so I
needn't be polite about condemning it.

But let's look at the big questions. What is our goal here?
The original goal was just to make expm1() available for MinGW
in the interim before they released the library version that
contained the files cited above. That happened in 2005, so what
purpose should this file now serve? I think we want to support:

  primary: gcc on GNU/Linux, and gcc (MinGW) on msw

  secondary: como with MinGW gcc on msw

  tertiary: msvc on msw; and anything else, e.g. gcc on apple

I tried googling for log1p or expm1 and msvc or msdn, and it
looks like they don't have these functions. So I assume we'll
want implementations for msvc and comeau-on-MinGW only (the
other compilers and platforms should have these functions).
Now, gcc-specific inline asm won't work with msvc, so it isn't
a solution unless we hide it in a dll, and I'd rather not go to
that much trouble. However, consider:

http://www.boost.org/doc/libs/1_34_1/doc/html/boost_math/math_special_functions.html#boost_math.math_special_functions.expm1
http://www.boost.org/doc/libs/1_34_1/doc/html/boost_math/math_special_functions.html#boost_math.math_special_functions.log1p

Is that the answer? I would hope that we could expunge 'expm1.c'
and just use boost's alternative. Now *that* would be a *very*
welcome change if you have time for it. I have deliberately
called these functions only in 'math_functors*.?pp', so a local
solution there would be fine. For MinGW, I would hope that the
libmingwex implementations (cvs citations above) are faster, and
that the same could be said of gcc with glibc; as long as that's
true, we'd want to use native implementations where available,
and boost only where we must.