Re: [boost] constexpr, cmath functions and other functions and distributions

Subject: Re: [boost] constexpr, cmath functions and other functions and distributions
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-07-31 10:55:07

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes
> Sent: 29 July 2016 14:07
> To: Boost Developers List
> Subject: Re: [boost] constexpr, cmath functions and other functions and distributions
> 
> On Thu, Jul 28, 2016 at 11:44 AM, Antony Polukhin <antoshkka_at_[hidden]>
> wrote:
> 
> > 2016-07-28 16:24 GMT+03:00 Paul A. Bristow <pbristow_at_[hidden]>:
> >
> > > Is there any support for making std::abs and friends constexpr where
> > > possible in future versions of the C++ Standard?
> > >
> >
> > Here are the bad news: C++ committee wishes to keep it possible for the
> > implementors of the Standard Library to reuse C headers.
> > I've tried to add constexpr to the <cstring> in
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html
> > The committee sad 'No', so I've removed the changes to <cstring> and only
> > then the paper passed into C++Next.
> >
> > There is a small chance that a paper on making some of the C math functions
> > constexpr may be accepted if functions are trivial to implement
> > efficiently.
> >
> 
> The chance of that happening is much increased if there are National Body
> comments to the C++17 ballot requesting constexpr C math functions.
> 
> So Paul should file a comment with the BSI (Roger Orr, IIRC), and anyone
> else who cares should file a comment with their National Body.

I have made some remarks on this already (though there were some dark mutterings about undefined behaviour).

> > I can write such paper and represent in to the C++ committee, but I'll need
> > a lot of help with:
> > * writing a list of C functions that could be simply implemented from
> > scratch without affecting performance (functions that usually take 1-3
> > lines to implement).
> > * implementing each of those function using constexpr
> >
> 
> Having such a paper also would increase the chance that the C++ committee
> will act.

>  > At least users will have the constexpr implementation in Boost.Math if the
> > paper won't be accepted.
> >
> >
> Again, the fact that Boost.Math has implemented such constexpr functions
> increases the chance that the committee will add them to the standard.

I don't want to overplay this - I've only done one function of one distribution as a 'proof of concept'.

It was tiresome and the prospect of doing all the functions and all the distributions is daunting. And making of code that will work
for constexpr-savvy and older compilers that are not isn't appealing either.

I also ran into the sand trying to do the erf function (needed for normal CDF).

Ironically it was in the complexity of extra code ensuring that the order of initialisation is correct,
one of the potentially important features of constexpr, if I understand correctly.

I also worry about creating three sets of cmath functions, some constexpr and some not yet, and others that are impossible like
frexp because they 'return' by assigning via a pointer.

This is going to be confusing?

GCC seems well on the way with its so-called __builtin_* versions. 

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

I am also sensitive to the feeling that this is not a top priority for C++ standardization compared to other new features, not just
in constexpr.

But making cmath functions constexpr surely should be a long-term ambition, especially for embedded IOT and phones.

HTH

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]