@@ -768,7 +768,8 @@ mod prim_tuple {}
768768///
769769/// This type can represent a wide range of decimal numbers, like `3.5`, `27`,
770770/// `-113.75`, `0.0078125`, `34359738368`, `0`, `-1`. So unlike integer types
771- /// (like `i32`), floating point types can represent non-integer numbers, too.
771+ /// (such as `i32`), floating point types can represent non-integer numbers,
772+ /// too.
772773///
773774/// However, being able to represent this wide range of numbers comes at the
774775/// cost of precision: floats can only represent some of the real numbers and
@@ -779,15 +780,12 @@ mod prim_tuple {}
779780/// often discard insignificant digits: `println!("{}", 1.0f32 / 5.0f32)` will
780781/// print `0.2`.
781782///
782- /// The precision is better for numbers near 0 and worse for large numbers. For
783- /// example, above 2<sup>24</sup>, not even all integers are representable.
784- ///
785783/// Additionally, `f32` can represent a couple of special values:
786784///
787785/// - `-0`: this is just due to how floats are encoded. It is semantically
788786/// equivalent to `0` and `-0.0 == 0.0` results in `true`.
789787/// - [∞](#associatedconstant.INFINITY) and
790- /// [- ∞](#associatedconstant.NEG_INFINITY): these result from calculations
788+ /// [− ∞](#associatedconstant.NEG_INFINITY): these result from calculations
791789/// like `1.0 / 0.0`.
792790/// - [NaN (not a number)](#associatedconstant.NAN): this value results from
793791/// calculations like `(-1.0).sqrt()`. NaN has some potentially unexpected
0 commit comments