pub struct DoubleKey(pub f64);Expand description
A wrapper type allowing f64 to be used as a key in collection types.
Conjure allows map<double, T> and set<double>, but Rust’s f64 type does not implement Eq and Ord,
preventing the direct translations of BTreeMap<f64, T> and BTreeSet<f64> from compiling. This wrapper type is
used to provide suitable trait implementations. The code generated by conjure-codegen will use this type,
resulting in BTreeMap<DoubleKey<f64>, T> and BTreeSet<DoubleKey<f64>>.
All trait implementations delegate directly to the inner type, with the exception of the PartialEq, Eq,
PartialOrd, and Ord methods.
Tuple Fields§
§0: f64Methods from Deref<Target = f64>§
pub const RADIX: u32 = 2
pub const MANTISSA_DIGITS: u32 = 53
pub const DIGITS: u32 = 15
pub const EPSILON: f64 = 2.2204460492503131e-16_f64
pub const MIN: f64 = -1.7976931348623157e+308_f64
pub const MIN_POSITIVE: f64 = 2.2250738585072014e-308_f64
pub const MAX: f64 = 1.7976931348623157e+308_f64
pub const MIN_EXP: i32 = -1021
pub const MAX_EXP: i32 = 1024
pub const MIN_10_EXP: i32 = -307
pub const MAX_10_EXP: i32 = 308
pub const NAN: f64
pub const INFINITY: f64
pub const NEG_INFINITY: f64
1.62.0 · Sourcepub fn total_cmp(&self, other: &f64) -> Ordering
pub fn total_cmp(&self, other: &f64) -> Ordering
Returns the ordering between self and other.
Unlike the standard partial comparison between floating point numbers,
this comparison always produces an ordering in accordance to
the totalOrder predicate as defined in the IEEE 754 (2008 revision)
floating point standard. The values are ordered in the following sequence:
- negative quiet NaN
- negative signaling NaN
- negative infinity
- negative numbers
- negative subnormal numbers
- negative zero
- positive zero
- positive subnormal numbers
- positive numbers
- positive infinity
- positive signaling NaN
- positive quiet NaN.
The ordering established by this function does not always agree with the
PartialOrd and PartialEq implementations of f64. For example,
they consider negative and positive zero equal, while total_cmp
doesn’t.
The interpretation of the signaling NaN bit follows the definition in the IEEE 754 standard, which may not match the interpretation by some of the older, non-conformant (e.g. MIPS) hardware implementations.
§Example
struct GoodBoy {
name: String,
weight: f64,
}
let mut bois = vec![
GoodBoy { name: "Pucci".to_owned(), weight: 0.1 },
GoodBoy { name: "Woofer".to_owned(), weight: 99.0 },
GoodBoy { name: "Yapper".to_owned(), weight: 10.0 },
GoodBoy { name: "Chonk".to_owned(), weight: f64::INFINITY },
GoodBoy { name: "Abs. Unit".to_owned(), weight: f64::NAN },
GoodBoy { name: "Floaty".to_owned(), weight: -5.0 },
];
bois.sort_by(|a, b| a.weight.total_cmp(&b.weight));
// `f64::NAN` could be positive or negative, which will affect the sort order.
if f64::NAN.is_sign_negative() {
assert!(bois.into_iter().map(|b| b.weight)
.zip([f64::NAN, -5.0, 0.1, 10.0, 99.0, f64::INFINITY].iter())
.all(|(a, b)| a.to_bits() == b.to_bits()))
} else {
assert!(bois.into_iter().map(|b| b.weight)
.zip([-5.0, 0.1, 10.0, 99.0, f64::INFINITY, f64::NAN].iter())
.all(|(a, b)| a.to_bits() == b.to_bits()))
}