Hi,

On Sun, 6 Mar 2022 09:32:33 +0100
Jens Maurer via Std-Proposals <std-proposals_at_[hidden]> wrote:
> This rationale is incorrect for implementations not
> providing binary floating-point. As far as I understand,
> there is no normative requirement for an implementation
> to supply binary floating-point; decimal floating-point
> (for example) is entirely fine, too.

Notice that currently we have sqrt2, sqrt3, inv_sqrt3, but no
inv_sqrt2. Why is that? Maybe because sqrt2/2 is an exact calculation?

P0631 also uses basically the same rationalization for not having some
fractions of pi there, I believe 2*pi would also be covered by this.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0631r8.pdf

"Virtually all existing implementations map floating-point types onto
some subset of ISO/IEC/IEEE 60559 types binary32, binary64 and
binary128. These types are stored internally as a combination of a sign
bit, a binary exponent and a binary normalized significand. If a ratio
of two floating-point numbers of the same type is an exact power of 2
(within a certain limit), their significands will be identical.
Therefore, in order to achieve the design goal 1), we don’t have to
provide replacements for both M_PI and M_PI_2 and M_PI_4. The user will
be able to divide the M_PI replacement by 2 and by 4 and achieve the
goals 2) and 3)."

I'm not saying that I agree with the rationale, but I say that having
tau/pi_times_2/twopi but not having inv_sqrt2 would be a little bit
weird. Maybe there are other constants too that are missing due to the
"power of two factor" rationalization.

> Thanks,
> Jens

Cheers,
Lénárd