Rollup merge of rust-lang#101671 - LingMan:ieee_754, r=Dylan-DPC

Fix naming format of IEEE 754 standard

Currently the documentation of f64::min refers to "IEEE-754 2008" while the documentation of f64::minimum refers to "IEEE 754-2019".
Note that one has the format IEEE,hyphen,number,space,year while the other is IEEE,space,number,hyphen,year. The official IEEE site [1] uses the later format and it is also the one most commonly used throughout the codebase.

Update all comments and - more importantly - documentation to consistently use the official format.

[1] https://standards.ieee.org/ieee/754/4211/

Author: Dylan-DPC

library/core/src/ffi/c_double.md

@@ -1,6 +1,6 @@
 Equivalent to C's `double` type.
 
-This type will almost always be [`f64`], which is guaranteed to be an [IEEE-754 double-precision float] in Rust. That said, the standard technically only guarantees that it be a floating-point number with at least the precision of a [`float`], and it may be `f32` or something entirely different from the IEEE-754 standard.
+This type will almost always be [`f64`], which is guaranteed to be an [IEEE 754 double-precision float] in Rust. That said, the standard technically only guarantees that it be a floating-point number with at least the precision of a [`float`], and it may be `f32` or something entirely different from the IEEE-754 standard.
 
-[IEEE-754 double-precision float]: https://en.wikipedia.org/wiki/IEEE_754
+[IEEE 754 double-precision float]: https://en.wikipedia.org/wiki/IEEE_754
 [`float`]: c_float

library/core/src/ffi/c_float.md

@@ -1,5 +1,5 @@
 Equivalent to C's `float` type.
 
-This type will almost always be [`f32`], which is guaranteed to be an [IEEE-754 single-precision float] in Rust. That said, the standard technically only guarantees that it be a floating-point number, and it may have less precision than `f32` or not follow the IEEE-754 standard at all.
+This type will almost always be [`f32`], which is guaranteed to be an [IEEE 754 single-precision float] in Rust. That said, the standard technically only guarantees that it be a floating-point number, and it may have less precision than `f32` or not follow the IEEE-754 standard at all.
 
-[IEEE-754 single-precision float]: https://en.wikipedia.org/wiki/IEEE_754
+[IEEE 754 single-precision float]: https://en.wikipedia.org/wiki/IEEE_754

library/core/src/num/dec2flt/decimal.rs

@@ -32,7 +32,7 @@ impl Default for Decimal {
 impl Decimal {
     /// The maximum number of digits required to unambiguously round a float.
     ///
-    /// For a double-precision IEEE-754 float, this required 767 digits,
+    /// For a double-precision IEEE 754 float, this required 767 digits,
     /// so we store the max digits + 1.
     ///
     /// We can exactly represent a float in radix `b` from radix 2 if

library/core/src/num/f32.rs

@@ -394,7 +394,7 @@ impl f32 {
 
     /// Not a Number (NaN).
     ///
-    /// Note that IEEE-754 doesn't define just a single NaN value;
+    /// Note that IEEE 754 doesn't define just a single NaN value;
     /// a plethora of bit patterns are considered to be NaN.
     /// Furthermore, the standard makes a difference
     /// between a "signaling" and a "quiet" NaN,
@@ -632,7 +632,7 @@ impl f32 {
     }
 
     /// Returns `true` if `self` has a positive sign, including `+0.0`, NaNs with
-    /// positive sign bit and positive infinity. Note that IEEE-754 doesn't assign any
+    /// positive sign bit and positive infinity. Note that IEEE 754 doesn't assign any
     /// meaning to the sign bit in case of a NaN, and as Rust doesn't guarantee that
     /// the bit pattern of NaNs are conserved over arithmetic operations, the result of
     /// `is_sign_positive` on a NaN might produce an unexpected result in some cases.
@@ -654,7 +654,7 @@ impl f32 {
     }
 
     /// Returns `true` if `self` has a negative sign, including `-0.0`, NaNs with
-    /// negative sign bit and negative infinity. Note that IEEE-754 doesn't assign any
+    /// negative sign bit and negative infinity. Note that IEEE 754 doesn't assign any
     /// meaning to the sign bit in case of a NaN, and as Rust doesn't guarantee that
     /// the bit pattern of NaNs are conserved over arithmetic operations, the result of
     /// `is_sign_negative` on a NaN might produce an unexpected result in some cases.
@@ -833,7 +833,7 @@ impl f32 {
     /// Returns the maximum of the two numbers, ignoring NaN.
     ///
     /// If one of the arguments is NaN, then the other argument is returned.
-    /// This follows the IEEE-754 2008 semantics for maxNum, except for handling of signaling NaNs;
+    /// This follows the IEEE 754-2008 semantics for maxNum, except for handling of signaling NaNs;
     /// this function handles all NaNs the same way and avoids maxNum's problems with associativity.
     /// This also matches the behavior of libm’s fmax.
     ///
@@ -853,7 +853,7 @@ impl f32 {
     /// Returns the minimum of the two numbers, ignoring NaN.
     ///
     /// If one of the arguments is NaN, then the other argument is returned.
-    /// This follows the IEEE-754 2008 semantics for minNum, except for handling of signaling NaNs;
+    /// This follows the IEEE 754-2008 semantics for minNum, except for handling of signaling NaNs;
     /// this function handles all NaNs the same way and avoids minNum's problems with associativity.
     /// This also matches the behavior of libm’s fmin.
     ///
@@ -1051,9 +1051,9 @@ impl f32 {
     /// It turns out this is incredibly portable, for two reasons:
     ///
     /// * Floats and Ints have the same endianness on all supported platforms.
-    /// * IEEE-754 very precisely specifies the bit layout of floats.
+    /// * IEEE 754 very precisely specifies the bit layout of floats.
     ///
-    /// However there is one caveat: prior to the 2008 version of IEEE-754, how
+    /// However there is one caveat: prior to the 2008 version of IEEE 754, how
     /// to interpret the NaN signaling bit wasn't actually specified. Most platforms
     /// (notably x86 and ARM) picked the interpretation that was ultimately
     /// standardized in 2008, but some didn't (notably MIPS). As a result, all

library/core/src/num/f64.rs

@@ -393,7 +393,7 @@ impl f64 {
 
     /// Not a Number (NaN).
     ///
-    /// Note that IEEE-754 doesn't define just a single NaN value;
+    /// Note that IEEE 754 doesn't define just a single NaN value;
     /// a plethora of bit patterns are considered to be NaN.
     /// Furthermore, the standard makes a difference
     /// between a "signaling" and a "quiet" NaN,
@@ -624,7 +624,7 @@ impl f64 {
     }
 
     /// Returns `true` if `self` has a positive sign, including `+0.0`, NaNs with
-    /// positive sign bit and positive infinity. Note that IEEE-754 doesn't assign any
+    /// positive sign bit and positive infinity. Note that IEEE 754 doesn't assign any
     /// meaning to the sign bit in case of a NaN, and as Rust doesn't guarantee that
     /// the bit pattern of NaNs are conserved over arithmetic operations, the result of
     /// `is_sign_positive` on a NaN might produce an unexpected result in some cases.
@@ -655,7 +655,7 @@ impl f64 {
     }
 
     /// Returns `true` if `self` has a negative sign, including `-0.0`, NaNs with
-    /// negative sign bit and negative infinity. Note that IEEE-754 doesn't assign any
+    /// negative sign bit and negative infinity. Note that IEEE 754 doesn't assign any
     /// meaning to the sign bit in case of a NaN, and as Rust doesn't guarantee that
     /// the bit pattern of NaNs are conserved over arithmetic operations, the result of
     /// `is_sign_negative` on a NaN might produce an unexpected result in some cases.
@@ -844,7 +844,7 @@ impl f64 {
     /// Returns the maximum of the two numbers, ignoring NaN.
     ///
     /// If one of the arguments is NaN, then the other argument is returned.
-    /// This follows the IEEE-754 2008 semantics for maxNum, except for handling of signaling NaNs;
+    /// This follows the IEEE 754-2008 semantics for maxNum, except for handling of signaling NaNs;
     /// this function handles all NaNs the same way and avoids maxNum's problems with associativity.
     /// This also matches the behavior of libm’s fmax.
     ///
@@ -864,7 +864,7 @@ impl f64 {
     /// Returns the minimum of the two numbers, ignoring NaN.
     ///
     /// If one of the arguments is NaN, then the other argument is returned.
-    /// This follows the IEEE-754 2008 semantics for minNum, except for handling of signaling NaNs;
+    /// This follows the IEEE 754-2008 semantics for minNum, except for handling of signaling NaNs;
     /// this function handles all NaNs the same way and avoids minNum's problems with associativity.
     /// This also matches the behavior of libm’s fmin.
     ///
@@ -1044,9 +1044,9 @@ impl f64 {
     /// It turns out this is incredibly portable, for two reasons:
     ///
     /// * Floats and Ints have the same endianness on all supported platforms.
-    /// * IEEE-754 very precisely specifies the bit layout of floats.
+    /// * IEEE 754 very precisely specifies the bit layout of floats.
     ///
-    /// However there is one caveat: prior to the 2008 version of IEEE-754, how
+    /// However there is one caveat: prior to the 2008 version of IEEE 754, how
     /// to interpret the NaN signaling bit wasn't actually specified. Most platforms
     /// (notably x86 and ARM) picked the interpretation that was ultimately
     /// standardized in 2008, but some didn't (notably MIPS). As a result, all

library/test/src/stats.rs

@@ -14,7 +14,7 @@ pub trait Stats {
     /// Sum of the samples.
     ///
     /// Note: this method sacrifices performance at the altar of accuracy
-    /// Depends on IEEE-754 arithmetic guarantees. See proof of correctness at:
+    /// Depends on IEEE 754 arithmetic guarantees. See proof of correctness at:
     /// ["Adaptive Precision Floating-Point Arithmetic and Fast Robust Geometric
     /// Predicates"][paper]
     ///