Andrew Kubera

Yeah that can be done.

PartialEqual has a "scale difference" issue, too: ``` let scaled_int_val = &self.int_val * ten_to_the((rhs.scale - self.scale) as u64); ``` Where that subtraction could cause an out-of-memory error allocating 10^(terabyte-sized-number) (and...

Oh no, that was the old version. It was [fixed in September](https://github.com/akubera/bigdecimal-rs/commit/94e2145d1bead3d7266b1f4335ddbe4bdf9b748e). I probably meant to fix `impl Ord` too but slipped by me.

Implementation is ready, and I included your example test. I'd like to write a few more tests to improve the coverage. https://github.com/akubera/bigdecimal-rs/compare/trunk...f/ImprovedOrd It now tries to cast the big ints...

I'm calling it for the night, but leaving myself a message: example : `cmp(1e-9223372036854775807, 1e+9223372036854775807)` panics as the difference of exponents is out of i64 domain. I'm not sure what...

That was fixed with a new `checked_diff(i64,i64) -> (Ordering, Option)` function. If the difference between the two numbers is greater than a u64, we return None in the tuple. Since...

Testing at the boundaries here lead to finding a similar panic in implementation of `eq`. That too has been fixed and I think should be faster with a non-allocating algorithm...

Now the hard part is making contrived test cases which avoid the optimizations.

I'm happy with result. It's now merged into trunk in commit https://github.com/akubera/bigdecimal-rs/commit/b34622dc5a71fa17f673d6545c89ec1a7fe5ba26. Let me know if that works for you.

A solution of this is being discussed in #117. But in general I think JSON specifies that numbers are f64, so using those as storage is not considered safe, and...