Date: Sun, 6 Mar 2022 11:42:11 +0100

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

> 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

Received on 2022-03-06 10:42:15