Re: [lmi] Where do we use boost::system?

[Greg Chicares]

On 2016-01-29 02:39, Vadim Zeitlin wrote:
> On Tue, 26 Jan 2016 06:51:10 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-01-26 04:32, Greg Chicares wrote:
[...]
> GC> I think the chain of causation here is that boost was upgraded to 1.38.0
> GC> in autotools only...and only for expm1() and log1p()...which AIUI can be
> GC> necessary only for msvc...but I didn't think msvc builds were 
> autotoolized.
> GC> So can we just revert 1.38.0 to 1.33.1 in 'configure.ac'? Whatever benefit
> GC> 1.38.0 may have brought, it's now an obstacle to upgrading to C++11, 
> whereas
> GC> 1.33.1 is not.
> 
>  We're clearly not going to ever use 1.38 now: either we'll stay with 1.33
> until the end of time or, more hopefully, we'll update to some 1.83 at some
> later moment. So I was wondering what should I do about the expm1() changes
> and the answer actually seems obvious: this function (and log1p() too, of
> course) is part of C++11

I hadn't realized that. Well, IEEE 754 is thirty years old, and it's about
time the language started to catch up.

> so we should be able just include <cmath> and use
> std::expm1() and std::log1p() and drop the existing expm1.c. Moreover, the
> current (2013+) versions of MSVS do provide these functions, so I won't
> even need the work around you proposed previously (see
> http://lists.nongnu.org/archive/html/lmi/2016-01/msg00054.html).

That's good news.

>  Would you accept a patch dropping expm1.c and using the standard functions
> instead (I will run the mortality rates test before submitting it, of
> course)?

If the glibc and MinGW-w64 implementations are both accurate, then "my"
implementation (ironic quotes because I was standing on the shoulders of
giants) is unnecessary, but otherwise I'll keep using it. Transcendental
library functions are not easy to implement correctly (there was original
research such as this:
  http://perso.ens-lyon.fr/jean-michel.muller/Intro-to-TMD.htm
as recently as 2003), and the implementations provided by our various
toolchains may leave room for discussion--e.g.:
  http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/?viewmonth=201104
(I'm not suggesting that you actually read that thread, but a quick glance
should show that serious people find plenty to discuss at length.)

However, actually testing this is not necessarily trivial. First, I'd
like to run our regression-test suite three ways:
 - lmi-gtk, native GNU/Linux
 - lmi-msw, cross compiled
 - lmi-msw, built natively
and compare the results, to establish a baseline. Then, if we try the
<cmath> implementation of these functions on all three and the outcome
is unobjectionable, then I'd favor such a patch. But there's a lot of
work to be done first, which may be displaced by higher-priority tasks,
so I think it would be unfair to ask you to prepare such a patch now.

Let me instead propose an alternative that solves the practical problem
at hand quickly: use <cmath> for msvc only. I have no reservation about
that and would accept such a patch right away.