Skip to content

Commit 081353c

Browse files
committed
add hyphen in floating-point
1 parent 93a72da commit 081353c

File tree

1 file changed

+12
-12
lines changed

1 file changed

+12
-12
lines changed

core/src/primitive_docs.rs

+12-12
Original file line numberDiff line numberDiff line change
@@ -1127,7 +1127,7 @@ impl<T> (T,) {}
11271127

11281128
#[rustc_doc_primitive = "f16"]
11291129
#[doc(alias = "half")]
1130-
/// A 16-bit floating point type (specifically, the "binary16" type defined in IEEE 754-2008).
1130+
/// A 16-bit floating-point type (specifically, the "binary16" type defined in IEEE 754-2008).
11311131
///
11321132
/// This type is very similar to [`prim@f32`] but has decreased precision because it uses half as many
11331133
/// bits. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on half-precision
@@ -1147,11 +1147,11 @@ mod prim_f16 {}
11471147

11481148
#[rustc_doc_primitive = "f32"]
11491149
#[doc(alias = "single")]
1150-
/// A 32-bit floating point type (specifically, the "binary32" type defined in IEEE 754-2008).
1150+
/// A 32-bit floating-point type (specifically, the "binary32" type defined in IEEE 754-2008).
11511151
///
11521152
/// This type can represent a wide range of decimal numbers, like `3.5`, `27`,
11531153
/// `-113.75`, `0.0078125`, `34359738368`, `0`, `-1`. So unlike integer types
1154-
/// (such as `i32`), floating point types can represent non-integer numbers,
1154+
/// (such as `i32`), floating-point types can represent non-integer numbers,
11551155
/// too.
11561156
///
11571157
/// However, being able to represent this wide range of numbers comes at the
@@ -1165,8 +1165,8 @@ mod prim_f16 {}
11651165
///
11661166
/// Additionally, `f32` can represent some special values:
11671167
///
1168-
/// - −0.0: IEEE 754 floating point numbers have a bit that indicates their sign, so −0.0 is a
1169-
/// possible value. For comparison −0.0 = +0.0, but floating point operations can carry
1168+
/// - −0.0: IEEE 754 floating-point numbers have a bit that indicates their sign, so −0.0 is a
1169+
/// possible value. For comparison −0.0 = +0.0, but floating-point operations can carry
11701170
/// the sign bit through arithmetic operations. This means −0.0 × +0.0 produces −0.0 and
11711171
/// a negative number rounded to a value smaller than a float can represent also produces −0.0.
11721172
/// - [∞](#associatedconstant.INFINITY) and
@@ -1211,17 +1211,17 @@ mod prim_f16 {}
12111211
/// both arguments were negative, then it is -0.0. Subtraction `a - b` is
12121212
/// regarded as a sum `a + (-b)`.
12131213
///
1214-
/// For more information on floating point numbers, see [Wikipedia][wikipedia].
1214+
/// For more information on floating-point numbers, see [Wikipedia][wikipedia].
12151215
///
12161216
/// *[See also the `std::f32::consts` module](crate::f32::consts).*
12171217
///
12181218
/// [wikipedia]: https://en.wikipedia.org/wiki/Single-precision_floating-point_format
12191219
///
12201220
/// # NaN bit patterns
12211221
///
1222-
/// This section defines the possible NaN bit patterns returned by floating point operations.
1222+
/// This section defines the possible NaN bit patterns returned by floating-point operations.
12231223
///
1224-
/// The bit pattern of a floating point NaN value is defined by:
1224+
/// The bit pattern of a floating-point NaN value is defined by:
12251225
/// - a sign bit.
12261226
/// - a quiet/signaling bit. Rust assumes that the quiet/signaling bit being set to `1` indicates a
12271227
/// quiet NaN (QNaN), and a value of `0` indicates a signaling NaN (SNaN). In the following we
@@ -1262,7 +1262,7 @@ mod prim_f16 {}
12621262
/// does not have any "extra" NaN payloads, then the output NaN is guaranteed to be preferred.
12631263
///
12641264
/// The non-deterministic choice happens when the operation is executed; i.e., the result of a
1265-
/// NaN-producing floating point operation is a stable bit pattern (looking at these bits multiple
1265+
/// NaN-producing floating-point operation is a stable bit pattern (looking at these bits multiple
12661266
/// times will yield consistent results), but running the same operation twice with the same inputs
12671267
/// can produce different results.
12681268
///
@@ -1276,7 +1276,7 @@ mod prim_f16 {}
12761276
/// (e.g. `min`, `minimum`, `max`, `maximum`); other aspects of their semantics and which IEEE 754
12771277
/// operation they correspond to are documented with the respective functions.
12781278
///
1279-
/// When an arithmetic floating point operation is executed in `const` context, the same rules
1279+
/// When an arithmetic floating-point operation is executed in `const` context, the same rules
12801280
/// apply: no guarantee is made about which of the NaN bit patterns described above will be
12811281
/// returned. The result does not have to match what happens when executing the same code at
12821282
/// runtime, and the result can vary depending on factors such as compiler version and flags.
@@ -1297,7 +1297,7 @@ mod prim_f32 {}
12971297

12981298
#[rustc_doc_primitive = "f64"]
12991299
#[doc(alias = "double")]
1300-
/// A 64-bit floating point type (specifically, the "binary64" type defined in IEEE 754-2008).
1300+
/// A 64-bit floating-point type (specifically, the "binary64" type defined in IEEE 754-2008).
13011301
///
13021302
/// This type is very similar to [`prim@f32`], but has increased precision by using twice as many
13031303
/// bits. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on double-precision
@@ -1311,7 +1311,7 @@ mod prim_f64 {}
13111311

13121312
#[rustc_doc_primitive = "f128"]
13131313
#[doc(alias = "quad")]
1314-
/// A 128-bit floating point type (specifically, the "binary128" type defined in IEEE 754-2008).
1314+
/// A 128-bit floating-point type (specifically, the "binary128" type defined in IEEE 754-2008).
13151315
///
13161316
/// This type is very similar to [`prim@f32`] and [`prim@f64`], but has increased precision by using twice
13171317
/// as many bits as `f64`. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on

0 commit comments

Comments
 (0)