Tracking Issue (take 2) for `more_float_constants`

[tgross35]

Feature gate: #![feature(more_float_constants)]

This is a tracking issue for additional constants in the {f16, f32, f64, f128}::consts modules. Most of these match C++, with the exception of 1/sqrt(2π) https://en.cppreference.com/w/cpp/numeric/constants.html.

The original tracking issue was #103883 but we lost the ability to edit the top post.

Public API

// in core::{f16, f32, f64, f128}::consts

/// The golden ratio (φ)
pub const PHI: f64 = 1.618033988749894848204586834365638118_f64;

/// The Euler-Mascheroni constant (γ)
pub const EGAMMA: f64 = 0.577215664901532860606512090082402431_f64;

/// 1/sqrt(π)
pub const FRAC_1_SQRT_PI: f64 = 0.564189583547756286948079451560772586_f64;

/// 1/sqrt(2π)
pub const FRAC_1_SQRT_2PI: f64 = 0.398942280401432677939946059934381868_f64;

/// sqrt(3)
pub const SQRT_3: f64 = 1.732050807568877293527446341505872367_f64;

/// 1/sqrt(3)
pub const FRAC_1_SQRT_3: f64 = 0.577350269189625764509148780501957456_f64;

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: ACP: Add a constant for the golden ratio (phi) to the floating point types libs-team#119
• ACP for FRAC_1_SQRT_2PI Add FRAC_1_SQRT_2PI constant libs-team#383
• Implementation: Add additional float constants #103836
• Add FRAC_1_SQRT_2PI Add FRAC_1_SQRT_2PI constant to f16/f32/f64/f128 #125253
• Add constants for f16 and f128 Add constants for f16 and f128 #123850
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Naming of the Euler-Mascheroni constant (gamma).
• FRAC_1_SQRT_2PI or FRAC_1_SQRT_TAU to match the existing TAU
• Any additional constants?
  • ln(3)
  • SQRT_5 Tracking Issue for more_float_constants #103883 (comment)
  • FRAC_1_SQRT_5 Tracking Issue for more_float_constants #103883 (comment)
• How do we decide whether or not a constant makes the cutoff?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[tgross35]

Since there is a proposal for more constants at rust-lang/libs-team#661, seems worth discussing whether there is interest in stabilizing the ones we already have. They have been unstably around since 2023, and most of the values have been stable for a few thousand years. There are a few unresolved questions on the issue.

@rustbot label +I-libs-api-nominated

Names for PHI and EGAMMA have come up a few times. Survey of other languages:

• C++: same (phi, egamma) https://en.cppreference.com/w/cpp/numeric/constants.html
• Julia: eulergamma and γ, golden and φ https://docs.julialang.org/en/v1/base/numbers/#Base.MathConstants.eulergamma
• Matlab: eulergamma https://www.mathworks.com/help/symbolic/eulergamma.html, no phi
• Numpy/Scipy: euler_gamma, golden and golden_ratio https://numpy.org/devdocs/reference/constants.html#numpy.euler_gamma https://docs.scipy.org/doc/scipy/reference/constants.html

[tgross35]

@joshuarayton replying from #103883 (comment):

I also think that EGAMMA should be renamed to GAMMA. Most of the time if the full name is stated, it is either "Euler's constant" or the "Euler-Mascheroni constant". When mentioning it briefly it is just referred to as "gamma". All the other constants named after Greek letters are also only named after their respective Greek letter: pi, tau, phi. So for consistency it should simply be named GAMMA.

Note that this is a soft conflict with the gamma function (tgamma in math.h) which is represented by an uppercase gamma.

My personal preference would be to closer match Julia and Numpy by calling these EULER_GAMMA and GOLDEN_RATIO (don't feel very strongly about phi though).

[joshuarayton]

Note that this is a soft conflict with the gamma function (tgamma in math.h) which is represented by an uppercase gamma.

My personal preference would be to closer match Julia and Numpy by calling these EULER_GAMMA and GOLDEN_RATIO (don't feel very strongly about phi though).

My personal preference would be GAMMA for the Euler-Mascheroni constant and PHI for the golden ratio. When these constants can be used multiple times in a single line of code, it's easier to have shorter names to prevent line wrapping.

I don't think GAMMA (constant) would conflict with gamma (function) because it is typical to have upper-case constant definitions. But I do accept this could be a reason against.

[kennytm]

i'm fine with GAMMA/EGAMMA/EULER_GAMMA. but if you need a shorter name you could always rename the import yourself.

use std::f64::consts::EULER_GAMMA as γ;

[Jules-Bertholet]

My personal preference would be to closer match Julia and Numpy by calling these EULER_GAMMA and GOLDEN_RATIO (don't feel very strongly about phi though).

This seems right to me as well. “Phi” and “gamma” can mean many things, it’s better to use unambiguous names. As @kennytm mentions, you can and should rename the import if needed; that gives the benefit of brevity without losing any clarity.