9

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

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

Community
  • 1
false
  • 221
  • 2
  • 7
  • 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 '15 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 '15 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 '15 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 '15 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 '15 at 16:52
  • @Ordous: Are you sure there is no other reason? I entirely agree with your reasoning, except that it does not exclude maybe other reasons for -0. I really should go through [this site](http://www.cs.berkeley.edu/~wkahan/) once more. – false Jun 23 '15 at 17:03
  • No other reason for what? For the switch to old standards? Yes, there are other reasons, compatibility mostly. No other reason to have -0? Well the author states that there is no valid reason under unums and believes it an advantage of the new system. – Ordous Jun 23 '15 at 17:12
  • Ordous, I think you should read up about the history of IEEE754. There are really good mathematical reasons for having +0 and -0. – gnasher729 Jan 12 '18 at 21:18
  • @gnasher729: ... that are not covered by Unum's open interval? – false Jan 12 '18 at 22:55

1 Answers1

3

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

Aconcagua
  • 186
  • 7