Struct BoundedFloat

Source

pub struct BoundedFloat<B>(/* private fields */);

Expand description

Finite f64 constrained by B.

NaN and infinities are rejected (finite_number). Bound errors reuse greater_than / greater_than_equal / less_than / less_than_equal.

Pydantic confloat takes numeric bounds as arguments; here they live on a FloatBounds type because stable Rust has no f64 const generics.

Implementations§

Source §

impl<B: FloatBounds> BoundedFloat

Source

pub fn new(value: f64) -> Result<Self, FieldError>

Validate finiteness and bounds, then wrap value.

Source §

Methods from Deref<Target = f64>§

1.43.0 · Source

pub const RADIX: u32 = 2

Source

pub const BITS: u32 = 64

1.43.0 · Source

pub const MANTISSA_DIGITS: u32 = 53

1.43.0 · Source

pub const DIGITS: u32 = 15

1.43.0 · Source

pub const EPSILON: f64 = 2.2204460492503131e-16_f64

1.43.0 · Source

pub const MIN: f64 = -1.7976931348623157e+308_f64

1.43.0 · Source

pub const MIN_POSITIVE: f64 = 2.2250738585072014e-308_f64

1.43.0 · Source

pub const MAX: f64 = 1.7976931348623157e+308_f64

1.43.0 · Source

pub const MIN_EXP: i32 = -1021

1.43.0 · Source

pub const MAX_EXP: i32 = 1024

1.43.0 · Source

pub const MIN_10_EXP: i32 = -307

1.43.0 · Source

pub const MAX_10_EXP: i32 = 308

1.43.0 · Source

pub const NAN: f64

1.43.0 · Source

pub const INFINITY: f64

1.43.0 · Source

pub const MANTISSA_MASK: u64 = 0x000f_ffff_ffff_ffff

1.62.0 · Source

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()))
}