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,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)).

(I am aware of Why is negative zero important?, Uses for negative floating point value)

  • 1
    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?
    – Ordous
    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.
    – false
    Jun 23, 2015 at 15:53
  • 5
    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.
    – Ordous
    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?
    – false
    Jun 23, 2015 at 16:27
  • 8
    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.
    – Ordous
    Jun 23, 2015 at 16:52

1 Answer 1


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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.