Actually, @TomP, it isn't just IBM hex arithmetic, although that format had other problems. You can only be guaranteed to be able to correctly round division and square root in a base that is a prime number. The algorithm that did not converge didn't take that fact into account. The actual IBM libraries did.
Which leaves out ALL practical computer implementations, where for storage efficiency in digital memory one needs base 2.
2 is a prime.
True. e would be an interesting base if it were feasible.
I haven't had to think about the IBM 360 floating-point disaster since about 1965, when the numerical-analysis professor whose textbooks I proofread started losing his hair and developing part of the basis for interval arithmetic in response to what IBM had wrought.
It was outsourced to an external crate some time before Rust 1.0 was released.
What you want is the num-traits crate.
In my humble opinion the inclusion of NaN is a very well defined concept. It simply results in a monadic type that allows the domain of a function to be extended to all floating point numbers. Otherwise the function needs to abort/panic, or throw an exception in other programming languages. So f64 could be regarded as something like Result<F64NonNaN,()>. To extend the concept in pure fashion, comparison operators would need to return values of type Result<bool,()>.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.