# How can unums emulate IEEE's negative zero?

I am currently reading "The End of Error - Unum Computing" by John Gustafson (Youtube). What I am still not sure about is how the cases handled in IEEE by negatively signed zero are handled with unums.

So, first of all, unums permit to represent certain exact values (similarly to floating points) and additionally permit to represent the open intervals that lie between exact values (including exact -∞ and ∞). So the complete real number line is represented by alternating precise values and open intervals:

-∞, (-∞,-maxreal), -maxreal, ... -smallsubnormal, (-smallsubnormal,0),

0,

(0,smallsubnormal), smallsubnormal, ... maxreal, (maxreal,∞), ∞

In this manner the (in IEEE tradition) exceptional values like underflow, and overflow are just some open intervals. In other words: these formerly special conditions now turn into regular cases.

IEEE's -∞ corresponds to the union of {-∞} and (-∞,-maxreal).

And signed zero now might be the intervals (-smallsubnormal,0) and (0,smallsubnormal).

However, 1/(-smallsubnormal,0) is now (-∞,-maxreal) and not -∞ alone. Whereas 1/0 is ∞.

What I am still hesitating about this is that in IEEE -0 and +0 compare equal. But they don't in unums. It seems that the mapping isn't a 100%. So I wonder if there are cornercases where the difference may show ((and if those cases are really relevant)).

• Why would you think that the mapping needs to be 1-to-1? The reasons stated in the questions you linked are a non-issue with unums, so why make a negative zero? Jun 23, 2015 at 15:48
• @Ordous: Because (Ch.18.1, p.257) "Unums are a superset of floats. Floats are simply unums for which the ubit is zero etc.etc." which all (including `guess`) suggests that one can more or less (and as a start) translate things literally. I am fully aware that a literal translation does not take full advantage of unums. Jun 23, 2015 at 15:53
• It's fairly difficult to argue against a quote without having the book at hand. However his slides in the IEEE presentation stated as an advantage of unum computing: "No need for underflow". Hence: no need for negative zero, as it is precisely underflow. Maybe you could extend this system to include a negative zero, but there is no reason to do so. Honestly negative 0 in IEEE is inconsistent with mathematics. Jun 23, 2015 at 16:20
• @Ordous: Underflow is handled by the open interval (-smallsubnormal,0) and its positive counterpart. So these are the closest thing to -0 and +0. But can this interval really act as if? Jun 23, 2015 at 16:27
• Underflow isn't "handled" here, it just doesn't exist. Negative 0 is a problem in IEEE and this standard is trying to fix it along with other things. You cannot and should not equate -0 and +0, but since in IEEE their difference is 0, they have to be equal. This paradox has no good solution. In unums they do have a difference, hence they cannot be equal. The entire point of the system is to fix problems in IEEE, but that means it's necessarily inconsistent with it. This is one of said inconsistencies. And the reason there is a proposed built-in system to use old standards in his book. Jun 23, 2015 at 16:52

Too long for a comment, so writing this as an answer...

The problem with IEEE is that we have three cases to differentiate, but only two representations for these:

• negative value, absolute value too small to represent – this is represented by IEEE -0.0 and might be easily mapped to `(-smallsubnormal,0)`
• value exactly null, represented by IEEE 0.0, mapped to `0`
• positive value too small to represent; this one has IEEE representation 0.0 as well but should be mapped to `(0, +smallsubnormal)`.

The problem now is not the negative zero, but that we cannot differentiate if a IEEE 0.0 is the second or third case! In other words: The mapping function from UNUM to IEEE is not bijective - and won't ever be, as for any other IEEE value, too, we never know if it is the exact or the interval one!

So I think it is absolutely fine to map -0.0 to `(-smallsubnormal,0)`, and we need to decide if IEEE 0.0 is rather to mapped to `0` or possibly better to `(0, +smallsubnormal)`. I personally tend to the first one, but that is not very authoritative...

As for comparison with IEEE (-0.0 being equal to 0.0): One should (almost) never ever compare for exact equality anyway (C or C++: == operator), but only for the difference's absolute value being smaller than some appropriate threshold. This problem is eliminated only partially even with UNUMS, as we now can compare for exact equality, if the u-bit is not set, but with it being set, we still do not really know...