search

jtempest / float_eq-rs

Compare IEEE floating point values for equality.
Other
39 stars 6 forks source link

Ulps types are poorly specified for composite types #15

Closed jtempest closed 4 years ago

jtempest commented 4 years ago

The library needs to decide whether Ulps types are fully fledged types intended for numeric manipulation, or if they are strictly debugging aids. For example, the MyComplex32 examples don't take into account what happens if one or more members have a valid difference in ULPs but the others do not. For example, given this call:

MyComplex32 { re: 1.0, im: 2.0 }.ulps_diff(&MyComplex32 { re: 1.0, im: -2.0 })

Should the result be None, or MyComplex32 { re: Some(0), im: None }. The former would appear to be more useful from a numerical algorithm standpoint, and the latter from a debugging standpoint. Given that float_eq is primarily a debugging aid (and FloatDiff already leans this way), I think it should be explicit about the diffs being for debugging, and thus more granularly specified.

jtempest commented 4 years ago

Suggestion: Fold FloatDiff into FloatEqDebug and rename it something like AssertFloatEqDebug. Also consider changing it to be a formatted output trait like Debug itself, rather than returning types that must be formatted themselves.

jtempest commented 4 years ago

This has been resolved by https://github.com/jtempest/float_eq-rs/commit/f8090cf5993dbf2484de10066ab0cb14e622548c.