Date: Sun, 6 Mar 2022 11:11:53 +0000

Isn't this a bit like our problems with utf-8 instead of all the confusion, or like using sine and cosine with radians? It could also be about sending a signal. I don't know if there are standardization efforts to use tau (didn't check!).

Our signal to the future programmer could also be about good patterns and mathematical unity.

I am doing game dev a lot, and very very often using glm::two_pi<float>() (from GLM library). If using Tau is a better habit, and I'm not a mathematician first, then I would support it.

Good patterns emerge when you start encouraging them.

Sent from Outlook Mobile<https://aka.ms/blhgte>

________________________________

From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>

Sent: Sunday, March 6, 2022 11:42:16 AM

To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>

Subject: Std-Proposals Digest, Vol 36, Issue 16

Send Std-Proposals mailing list submissions to

std-proposals_at_[hidden]

To subscribe or unsubscribe via the World Wide Web, visit

https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

or, via email, send a message with subject or body 'help' to

std-proposals-request_at_[hidden]

You can reach the person managing the list at

std-proposals-owner_at_[hidden]

When replying, please edit your Subject line so it is more specific

than "Re: Contents of Std-Proposals digest..."

Today's Topics:

1. Introducing std::numbers::tau (Desmond Gold Bongcawel)

2. Introducing std::numbers::tau (Desmond Gold Bongcawel)

3. Re: Introducing std::numbers::tau (Arthur O'Dwyer)

4. Re: Introducing std::numbers::tau (Jens Maurer)

5. Re: Introducing std::numbers::tau (L?n?rd Szolnoki)

6. Re: Introducing std::numbers::tau (Jens Maurer)

----------------------------------------------------------------------

Message: 1

Date: Sat, 5 Mar 2022 22:45:10 +0800

From: Desmond Gold Bongcawel <desmondbongcawel922_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: [std-proposals] Introducing std::numbers::tau

Message-ID:

<CA+xKOkLxY82RH-6cyZ6JSfL_gJyDzH72=-hD3k81ZbW5p036kQ_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

I know this is a silly minor addition, but this would help reduce the

duplication of writing (std::numbers::pi * 2) whenever they exist in

specific formulas.

The constant tau already existed in other programming languages such as C#,

rust, etc.

Synopsis:

namespace std::numbers {

// ...

template<class T> inline constexpr T tau_v = /* unspecified */;

// ...

template<floating_point T> inline constexpr T tau_v<T> = /* see

description */;

// ...

inline constexpr double tau = tau_v<double>;

} // namespace std::numbers

In variable template std::numbers::tau_v

expression equivalent to:

2 * std::numbers::pi_v<T>

template <floating_point T>

inline constexpr T tau_v<T> = T(6.283185307179586476925286766559005768L);

-------------- next part --------------

HTML attachment scrubbed and removed

------------------------------

Message: 2

Date: Sat, 5 Mar 2022 22:48:39 +0800

From: Desmond Gold Bongcawel <desmondbongcawel922_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: [std-proposals] Introducing std::numbers::tau

Message-ID:

<CA+xKOkKuzt8LjuQ5thdxMtjpK=zNo=0ntXkg0z90Khvn7wT1Sw_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

[resent the mail]

I know this is a silly minor addition, but this would help reduce the

duplication of writing (std::numbers::pi * 2) wherever they exist in some

particular computations such as computing the circumference of the circle.

The constant tau already existed in other programming languages such as C#,

rust, etc.

Synopsis in <numbers>:

namespace std::numbers {

// ...

template<class T> inline constexpr T tau_v = /* unspecified */;

// ...

template<floating_point T> inline constexpr T tau_v<T> = /* see

description */;

// ...

inline constexpr double tau = tau_v<double>;

} // namespace std::numbers

In variable template std::numbers::tau_v

expression equivalent to:

2 * std::numbers::pi_v<T>

template <floating_point T>

inline constexpr T tau_v<T> = T(6.283185307179586476925286766559005768L);

-------------- next part --------------

HTML attachment scrubbed and removed

------------------------------

Message: 3

Date: Sat, 5 Mar 2022 20:19:12 -0500

From: "Arthur O'Dwyer" <arthur.j.odwyer_at_[hidden]>

To: Std-Proposals <std-proposals_at_[hidden]>

Cc: Desmond Gold Bongcawel <desmondbongcawel922_at_[hidden]>

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID:

<CADvuK0LMOfPDy4i1Bwbt9j4c8RVJhTASMvruziQSJx+8hn8Dog_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

On Sat, Mar 5, 2022 at 9:48 AM Desmond Gold Bongcawel via Std-Proposals <

std-proposals_at_[hidden]> wrote:

> [resent the mail]

>

> I know this is a silly minor addition, but this would help reduce the

> duplication of writing (std::numbers::pi * 2) wherever they exist in some

> particular computations such as computing the circumference of the circle.

>

> The constant tau already existed in other programming languages such as

> C#, rust, etc.

>

https://doc.rust-lang.org/stable/std/f64/consts/constant.TAU.html

https://docs.microsoft.com/en-us/dotnet/api/system.math.tau

https://stackoverflow.com/questions/13426562/why-does-math-h-define-pi-pi-2-2-pi-but-not-2pi

I'm familiar with https://tauday.com/tau-manifesto , but still, you're

going to have an uphill battle explaining why "tau_v" would be a better

name than "twopi_v". The only obvious benefit of naming it "tau" would be

that 100 years from now, when everyone's using tau for all their

mathematical needs, C++ won't be ridiculed for having outdated nomenclature

that feels like it's stuck in the (400s BC through 2000s). ;)

expression equivalent to:

> 2 * std::numbers::pi_v<T>

>

(For dummies like me who might also be fooled by this at first: No, this is

not "shifting in a zero from the right" and thus losing one bit of

precision in the mantissa. It's just taking M_PI and increasing the

exponent by 1. So this is indeed mathematically correct.)

?Arthur

-------------- next part --------------

HTML attachment scrubbed and removed

------------------------------

Message: 4

Date: Sun, 6 Mar 2022 09:32:33 +0100

From: Jens Maurer <Jens.Maurer_at_[hidden]>

To: std-proposals_at_[hidden]

Cc: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>, Desmond Gold Bongcawel

<desmondbongcawel922_at_[hidden]>

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID: <6f944e27-c329-a9f3-c90b-187f35304586_at_[hidden]>

Content-Type: text/plain; charset=UTF-8

On 06/03/2022 02.19, Arthur O'Dwyer via Std-Proposals wrote:

> On Sat, Mar 5, 2022 at 9:48 AM Desmond Gold Bongcawel via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:

>

> [resent the mail]

>

> I know this is a silly minor addition, but this would help reduce the duplication of writing (std::numbers::pi * 2) wherever they exist in?some particular?computations such as computing the circumference of the circle.

>

> The constant tau already existed in other programming languages such as C#, rust, etc.

>

>

> https://doc.rust-lang.org/stable/std/f64/consts/constant.TAU.html <https://doc.rust-lang.org/stable/std/f64/consts/constant.TAU.html>

> https://docs.microsoft.com/en-us/dotnet/api/system.math.tau <https://docs.microsoft.com/en-us/dotnet/api/system.math.tau>

> https://stackoverflow.com/questions/13426562/why-does-math-h-define-pi-pi-2-2-pi-but-not-2pi <https://stackoverflow.com/questions/13426562/why-does-math-h-define-pi-pi-2-2-pi-but-not-2pi>

>

> I'm familiar with?https://tauday.com/tau-manifesto <https://tauday.com/tau-manifesto> , but still, you're going to have an uphill battle?explaining why "tau_v" would be a better name than "twopi_v".

Yes, rationale needed.

> The only obvious benefit of naming it "tau" would be that 100 years from now, when everyone's using tau for all their mathematical needs, C++ won't be ridiculed for having outdated nomenclature that feels like it's stuck in the (400s BC through 2000s). ;)

>

> expression equivalent to:

> ? 2 * std::numbers::pi_v<T>

>

>

> (For dummies like me who might also be fooled by this at first: No, this is not "shifting in a zero from the right" and thus losing one bit of precision in the mantissa. It's just taking M_PI and increasing the exponent by 1. So this is indeed mathematically correct.)

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.

Thanks,

Jens

------------------------------

Message: 5

Date: Sun, 6 Mar 2022 09:45:34 +0000

From: L?n?rd Szolnoki <cpp_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID: <20220306094534.657508e1_at_[hidden]>

Content-Type: text/plain; charset=UTF-8

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

------------------------------

Message: 6

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

From: Jens Maurer <Jens.Maurer_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID: <470d19cf-8283-d302-4331-9ad59e7fc84d_at_[hidden]>

Content-Type: text/plain; charset=UTF-8

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

------------------------------

Subject: Digest Footer

Std-Proposals mailing list

Std-Proposals_at_[hidden]

https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

------------------------------

End of Std-Proposals Digest, Vol 36, Issue 16

*********************************************

Our signal to the future programmer could also be about good patterns and mathematical unity.

I am doing game dev a lot, and very very often using glm::two_pi<float>() (from GLM library). If using Tau is a better habit, and I'm not a mathematician first, then I would support it.

Good patterns emerge when you start encouraging them.

Sent from Outlook Mobile<https://aka.ms/blhgte>

________________________________

From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>

Sent: Sunday, March 6, 2022 11:42:16 AM

To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>

Subject: Std-Proposals Digest, Vol 36, Issue 16

Send Std-Proposals mailing list submissions to

std-proposals_at_[hidden]

To subscribe or unsubscribe via the World Wide Web, visit

https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

or, via email, send a message with subject or body 'help' to

std-proposals-request_at_[hidden]

You can reach the person managing the list at

std-proposals-owner_at_[hidden]

When replying, please edit your Subject line so it is more specific

than "Re: Contents of Std-Proposals digest..."

Today's Topics:

1. Introducing std::numbers::tau (Desmond Gold Bongcawel)

2. Introducing std::numbers::tau (Desmond Gold Bongcawel)

3. Re: Introducing std::numbers::tau (Arthur O'Dwyer)

4. Re: Introducing std::numbers::tau (Jens Maurer)

5. Re: Introducing std::numbers::tau (L?n?rd Szolnoki)

6. Re: Introducing std::numbers::tau (Jens Maurer)

----------------------------------------------------------------------

Message: 1

Date: Sat, 5 Mar 2022 22:45:10 +0800

From: Desmond Gold Bongcawel <desmondbongcawel922_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: [std-proposals] Introducing std::numbers::tau

Message-ID:

<CA+xKOkLxY82RH-6cyZ6JSfL_gJyDzH72=-hD3k81ZbW5p036kQ_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

I know this is a silly minor addition, but this would help reduce the

duplication of writing (std::numbers::pi * 2) whenever they exist in

specific formulas.

The constant tau already existed in other programming languages such as C#,

rust, etc.

Synopsis:

namespace std::numbers {

// ...

template<class T> inline constexpr T tau_v = /* unspecified */;

// ...

template<floating_point T> inline constexpr T tau_v<T> = /* see

description */;

// ...

inline constexpr double tau = tau_v<double>;

} // namespace std::numbers

In variable template std::numbers::tau_v

expression equivalent to:

2 * std::numbers::pi_v<T>

template <floating_point T>

inline constexpr T tau_v<T> = T(6.283185307179586476925286766559005768L);

-------------- next part --------------

HTML attachment scrubbed and removed

------------------------------

Message: 2

Date: Sat, 5 Mar 2022 22:48:39 +0800

From: Desmond Gold Bongcawel <desmondbongcawel922_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: [std-proposals] Introducing std::numbers::tau

Message-ID:

<CA+xKOkKuzt8LjuQ5thdxMtjpK=zNo=0ntXkg0z90Khvn7wT1Sw_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

[resent the mail]

I know this is a silly minor addition, but this would help reduce the

duplication of writing (std::numbers::pi * 2) wherever they exist in some

particular computations such as computing the circumference of the circle.

The constant tau already existed in other programming languages such as C#,

rust, etc.

Synopsis in <numbers>:

namespace std::numbers {

// ...

template<class T> inline constexpr T tau_v = /* unspecified */;

// ...

template<floating_point T> inline constexpr T tau_v<T> = /* see

description */;

// ...

inline constexpr double tau = tau_v<double>;

} // namespace std::numbers

In variable template std::numbers::tau_v

expression equivalent to:

2 * std::numbers::pi_v<T>

template <floating_point T>

inline constexpr T tau_v<T> = T(6.283185307179586476925286766559005768L);

-------------- next part --------------

HTML attachment scrubbed and removed

------------------------------

Message: 3

Date: Sat, 5 Mar 2022 20:19:12 -0500

From: "Arthur O'Dwyer" <arthur.j.odwyer_at_[hidden]>

To: Std-Proposals <std-proposals_at_[hidden]>

Cc: Desmond Gold Bongcawel <desmondbongcawel922_at_[hidden]>

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID:

<CADvuK0LMOfPDy4i1Bwbt9j4c8RVJhTASMvruziQSJx+8hn8Dog_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

On Sat, Mar 5, 2022 at 9:48 AM Desmond Gold Bongcawel via Std-Proposals <

std-proposals_at_[hidden]> wrote:

> [resent the mail]

>

> I know this is a silly minor addition, but this would help reduce the

> duplication of writing (std::numbers::pi * 2) wherever they exist in some

> particular computations such as computing the circumference of the circle.

>

> The constant tau already existed in other programming languages such as

> C#, rust, etc.

>

https://doc.rust-lang.org/stable/std/f64/consts/constant.TAU.html

https://docs.microsoft.com/en-us/dotnet/api/system.math.tau

https://stackoverflow.com/questions/13426562/why-does-math-h-define-pi-pi-2-2-pi-but-not-2pi

I'm familiar with https://tauday.com/tau-manifesto , but still, you're

going to have an uphill battle explaining why "tau_v" would be a better

name than "twopi_v". The only obvious benefit of naming it "tau" would be

that 100 years from now, when everyone's using tau for all their

mathematical needs, C++ won't be ridiculed for having outdated nomenclature

that feels like it's stuck in the (400s BC through 2000s). ;)

expression equivalent to:

> 2 * std::numbers::pi_v<T>

>

(For dummies like me who might also be fooled by this at first: No, this is

not "shifting in a zero from the right" and thus losing one bit of

precision in the mantissa. It's just taking M_PI and increasing the

exponent by 1. So this is indeed mathematically correct.)

?Arthur

-------------- next part --------------

HTML attachment scrubbed and removed

------------------------------

Message: 4

Date: Sun, 6 Mar 2022 09:32:33 +0100

From: Jens Maurer <Jens.Maurer_at_[hidden]>

To: std-proposals_at_[hidden]

Cc: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>, Desmond Gold Bongcawel

<desmondbongcawel922_at_[hidden]>

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID: <6f944e27-c329-a9f3-c90b-187f35304586_at_[hidden]>

Content-Type: text/plain; charset=UTF-8

On 06/03/2022 02.19, Arthur O'Dwyer via Std-Proposals wrote:

> On Sat, Mar 5, 2022 at 9:48 AM Desmond Gold Bongcawel via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:

>

> [resent the mail]

>

> I know this is a silly minor addition, but this would help reduce the duplication of writing (std::numbers::pi * 2) wherever they exist in?some particular?computations such as computing the circumference of the circle.

>

> The constant tau already existed in other programming languages such as C#, rust, etc.

>

>

> https://doc.rust-lang.org/stable/std/f64/consts/constant.TAU.html <https://doc.rust-lang.org/stable/std/f64/consts/constant.TAU.html>

> https://docs.microsoft.com/en-us/dotnet/api/system.math.tau <https://docs.microsoft.com/en-us/dotnet/api/system.math.tau>

> https://stackoverflow.com/questions/13426562/why-does-math-h-define-pi-pi-2-2-pi-but-not-2pi <https://stackoverflow.com/questions/13426562/why-does-math-h-define-pi-pi-2-2-pi-but-not-2pi>

>

> I'm familiar with?https://tauday.com/tau-manifesto <https://tauday.com/tau-manifesto> , but still, you're going to have an uphill battle?explaining why "tau_v" would be a better name than "twopi_v".

Yes, rationale needed.

> The only obvious benefit of naming it "tau" would be that 100 years from now, when everyone's using tau for all their mathematical needs, C++ won't be ridiculed for having outdated nomenclature that feels like it's stuck in the (400s BC through 2000s). ;)

>

> expression equivalent to:

> ? 2 * std::numbers::pi_v<T>

>

>

> (For dummies like me who might also be fooled by this at first: No, this is not "shifting in a zero from the right" and thus losing one bit of precision in the mantissa. It's just taking M_PI and increasing the exponent by 1. So this is indeed mathematically correct.)

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.

Thanks,

Jens

------------------------------

Message: 5

Date: Sun, 6 Mar 2022 09:45:34 +0000

From: L?n?rd Szolnoki <cpp_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID: <20220306094534.657508e1_at_[hidden]>

Content-Type: text/plain; charset=UTF-8

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

------------------------------

Message: 6

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

From: Jens Maurer <Jens.Maurer_at_[hidden]>

To: std-proposals_at_[hidden]

Subject: Re: [std-proposals] Introducing std::numbers::tau

Message-ID: <470d19cf-8283-d302-4331-9ad59e7fc84d_at_[hidden]>

Content-Type: text/plain; charset=UTF-8

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

------------------------------

Subject: Digest Footer

Std-Proposals mailing list

Std-Proposals_at_[hidden]

https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

------------------------------

End of Std-Proposals Digest, Vol 36, Issue 16

*********************************************

Received on 2022-03-06 11:11:57