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

[Greg Chicares]

On 2008-06-23 20:17Z, Vadim Zeitlin wrote:
> On Mon, 23 Jun 2008 20:03:39 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> # boost: the build system provided is not free.
> GC> [and it's unique to boost AFAICT]
> 
>  I'm not sure about the source of this assertion, do you have any more
> information about this?

No, I don't. These days, I'm trying to be more careful about documenting
everything, but that statement dates from 'workhorse.make' rev. 1.1, and
I don't remember the reason clearly, but I imagine it had something to
do with this:
  http://www.perforce.com/perforce/price.html
However...

> I thought that Boost Jam was distributed under the
> same (very permissive but definitely free) Boost Software Licence as the
> rest of Boost. And seeing that Debian has no qualms in distributing Boost
> (including the libraries which require to be built) I'd be very surprised
> if there were a problem here.

...if Debian says it's okay, then most likely it is.

Still, if we can avoid Yet Another Make Alternative, then we should.
I know, in theory, you cross your fingers and everything just works;
but in practice, when it breaks, I have to fix it.

> GC> Do you think it would be hard to autotoolize boost::filesystem so that
> GC> we could use it as a shared library?
> 
>  No, it wouldn't.

That's good to hear. A makefile along the lines of
  boost/libs/regex/build/gcc.mak
would be quite sufficient, if that's easier. In fact, if you want
to work on that now, I'd be glad to have it, though I'm in no rush.

>  OTOH I did realize that my own suggestion to require 1.35 would be a
> problem for the Linux builds: 1.35 is not even in Debian testing yet and
> Debian stable only has 1.33, 1.34 is in testing (so I use it only in a
> chroot as my main system is stable).

Let's think this through. We ought to upgrade if we can. Right now,
our motivation for wanting boost-1.35 is expm1l() and log1pl(), and
Debian's glibc already provides them; so our need is restricted to
comeau and msvc. So we could upgrade boost now for msw only. But
that means we'd need to write preprocessor conditionals that we'd
later remove, which it's better to avoid.

Or we could upgrade the existing 'expm1.c': copy in the expm1l()
and log1p() code from MinGW cvs, and fix the __COMO__ conditionals;
but we'd throw that away, too, soon enough.

Or we could just live with a ghastly workaround for now, for comeau
and msvc only. It'll compile and run, but the calculations won't be
as accurate as we'd like, and they won't match gcc's.

>  So everything being said I think it could be simpler to just copy the 3
> files boost/math/special_functions/{log1p,expm1}.hpp and details/series.hpp
> to LMI source tree and simply use them.
> 
>  What do you think?

Have you tried that, just to make sure they can truly stand alone;
or can you easily remove any dependencies they might have?

If so, then I wouldn't mind doing this for now. We're looking for
a temporary workaround that doesn't require much throwaway work.
Do they have expm1l() and log1pl() with the '-l' suffix?