On 06/03/2022 10.45, Lénárd Szolnoki via Std-Proposals wrote:
> 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.

Good points, and thus good arguments against having "tau = 2*pi" in the
first place.

Jens