Re: [lmi] [lmi-commits] master ee120a2d 1/3: Improve documentation; add 'const'

[Greg Chicares]

On 5/28/22 14:36, Vadim Zeitlin wrote:
> On Fri, 27 May 2022 20:49:10 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC>     As an extension, gcc would allow
> GC>     -            static T const z0 = std::pow
> GC>     +            constexpr T z0 = std::pow
> GC>     but not all compilers support that.
> 
>  And looking at https://github.com/cplusplus/papers/issues/168 it seems
> quite likely that they won't support it even in C++23, unfortunately. This
> is really disappointing, I wanted to reply to this message saying that soon
> they will, but I was clearly over-optimistic.

Expressing myself with somewhat less reserve: what's holding them back?
 - gcc provides enough real-world experience
 - of course, specify the constexpr environment, like C99 Annex F
 - behavior differs between constexpr and run time: so what?
     ("PI * 3.0" already depends on directed rounding)
 - "is this the right time"? the right time was concurrent with
     IEEE 754-1985, or C1989, or at least C1999; if not now, when?
 - different names for <cmath> functions that have correct rounding?
     and reserve old names for...what, incorrectly-rounded functions?
The only substantive issue I see is directed rounding--which, AIUI,
is in IEEE 754 not because it's often useful, but because it's cheap:

https://hal.archives-ouvertes.fr/hal-03195756/file/2021_Posit_IEEE754_Hardware_Cost.pdf

| Among the features that the posit system discards as useless, most
| (in particular overflow management, NaNs, and directed rounding mode)
| were designed to be implementable at very little cost

I want a ln implementation that's correctly rounded to nearest or even;
does anyone care about one that rounds correctly toward +infinity?

One of the papers brings out the old chestnut about a correctly-rounded
cosine of 10^18; ignore that, define std::cosine only over 0 < θ < 2π,
and move forward.