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
*********************************************