There is an observable difference in the generated code if floating point traps are enabled. For example, if `radius * 2` overflows, then the trap happens there, before the multiplication by Pi. The overflow would happen anyway (because Pi > 1); it's just a question of where. For clang, I tried adding the compiler flag `-ffp-model=fast`. Then all four functions precompute tau and the function body is just `mulsd`. Intel uses this setting by default in their `icpx` compiler. The clang default is `-ffp-model=precise`. According to the documentation, this implies `-ffp-exception-behavior=ignore` and `-fno-associative-math`. Thiago observes that multiplication by 2 is associative in binary floating point if exception behavior is ignored, so maybe clang could perform this optimization when `-ffp-model=precise`, but not when `-ffp-model=strict`. Of course, `radius * std::numbers::tau` is a single multiply, even when `-ffp-model=strict`. --Paul -----Original message----- From: Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Sent: Saturday, August 24 2024, 8:01 pm To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> Cc: Thiago Macieira <thiago_at_[hidden]> Subject: Re: [std-proposals] Proposal to add the circle constant "tau" On Saturday 24 August 2024 11:28:06 GMT-7 Aaron Franke via Std-Proposals wrote: > In order to have the constants grouped so they are evaluated at compile > time, it would need to be `radius * (2 * std::numbers::pi)`, or simply > `radius * std::numbers::tau`. Providing a single constant for this > extremely common value (more commonly needed than pi by itself) will help > avoid mistakes such as `radius * 2 * std::numbers::pi`. That's the state of the art today: https://gcc.godbolt.org/z/WEfcfs5vh But the implementations are not required to do it that way. All four different implementations you can find in that link above always produce the same result, even in the case of NaNs and infinities. It just happens the compilers don't optimise it.