Negative zero can create other negative numbers

[tdelmas]

    #[test]
    fn test_neg() {
        let one: UnsignedF64 = unsigned::UnsignedF64::new(1.0).unwrap();
        let neg_zero = unsigned::UnsignedF64::new(-0.0).unwrap();

        let neg_inf: UnsignedF64 = one / neg_zero;
        let neg_pi_by_two = neg_inf.atan() ; // Return PI/2 for -Inf
        let neg_one = neg_pi_by_two.abs() / neg_pi_by_two;

        println!("neg_one={neg_one}");

        assert!(neg_one >= neg_zero);
    }

running 1 test
neg_one=-1
thread 'tests::test_neg' panicked at 'assertion failed: neg_one >= neg_zero', src\lib.rs:109:9

Disclaimer: I'm the author of https://crates.io/crates/typed_floats and the complexity of the problem can be seen in https://docs.rs/typed_floats/latest/typed_floats/trait.Float.html

[hydrogen602]

I see. Given that this problem is a lot more complex that I thought and since your library deals with this problem much more throughly, I will put a note on the readme to recommend your library as it doesn't make sense for me to re-implement the same logic that already exists in yours.

[tdelmas]

Thank you for the vote of confidence.

That said, I do think your crate is interesting and useful if someone needs a very simple crate to handle positive numbers with a few methods, and I do think it can be fixed.

[hydrogen602]

If I convert -0.0 to 0.0 in UnsignedF64::new, it will fix this specific issue, but I'm wondering if there are other ways to get -0.0 from just positive numbers or +0.0?

[tdelmas]

I'm wondering if there are other ways to get -0.0 from just positive numbers or +0.0?

With functions like sin or cos. But nothing unexpected. The biggest pitfalls, from memory, are max(-0.0, 0.0) that may return -0.0, and sqrt(-0.0) that returns -0.0.

I like your solution, btw.