Update signed fmt/-0f32 docs

"semantic equivalence" is too strong a phrasing here, which is why
actually explaining what kind of circumstances might produce a -0
was chosen instead.
This commit is contained in:
Jubilee Young 2020-10-31 17:21:23 -07:00
parent 74db93ed2d
commit 6fdb8d8b36
2 changed files with 7 additions and 6 deletions

View File

@ -157,9 +157,8 @@
//!
//! * `+` - This is intended for numeric types and indicates that the sign
//! should always be printed. Positive signs are never printed by
//! default, and the negative sign is only printed by default for the
//! `Signed` trait. This flag indicates that the correct sign (`+` or `-`)
//! should always be printed.
//! default, and the negative sign is only printed by default for signed values.
//! This flag indicates that the correct sign (`+` or `-`) should always be printed.
//! * `-` - Currently not used
//! * `#` - This flag indicates that the "alternate" form of printing should
//! be used. The alternate forms are:

View File

@ -805,10 +805,12 @@ mod prim_tuple {}
/// often discard insignificant digits: `println!("{}", 1.0f32 / 5.0f32)` will
/// print `0.2`.
///
/// Additionally, `f32` can represent a couple of special values:
/// Additionally, `f32` can represent some special values:
///
/// - `-0`: this is just due to how floats are encoded. It is semantically
/// equivalent to `0` and `-0.0 == 0.0` results in `true`.
/// - `-0`: this value exists due to how floats are encoded. -0 == 0 is true, but for other
/// operations they are not equal and the difference can be useful to certain algorithms.
/// For example, operations on negative numbers that underflow to 0 will usually generate -0
/// instead of +0.
/// - [∞](#associatedconstant.INFINITY) and
/// [−∞](#associatedconstant.NEG_INFINITY): these result from calculations
/// like `1.0 / 0.0`.