1

My professor went over a practice final exam question where we're working with IEEE floating point format. The Binary is a 5 bit representation where in one of the cases we worked with Minus Zero. Each representation has 1 sign bit, 3 exponent bits, and 1 fraction bit.

He went over it as having a binary representation of 1 0000, which I understand. The significand M is 0, which I understand because denormalized values have a significand M = f = 0 since the fraction field is 0.

However, he put the exponent value E as -3.

This, I do not understand. I thought minus 0 was denormalized! My book says

"When the exponent field is all zeros, the represented number is in denormalized form. In this case, the exponent value is E = 1 − Bias, and the significand value is M = f , that is, the value of the fraction field without an implied leading 1."

Since minus 0 is denormalized, E should equal 1 - 3 (the bias) = -2, right?

In my book, positive 0 with IEEE 8-bit floating point format with 4 exponent bits, 3 fraction bits, and a bias of 7 (2^4 -1) has an exponent value E of -6, which is correct since E = 1 - 7 (bias) because it's denormalized.

Why is it different in this case? Or did my professor make a mistake?

Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
Rafi
  • 1,902
  • 3
  • 24
  • 46

1 Answers1

3

Zero uses the same exponent as denormals, and like them does not have a leading 1 bit when its representation is decoded. You can call it “denormal” if you want, just be aware that others may use the word in a stricter sense (i.e. consider 0 and denormals disjoint classes of floating-point numbers).

As for the -3, it's probably a mistake in the value of the bias when converting between the biased and unbiased versions of the exponent. Don't read too much into it. The important thing is to remember that the exponent for denormals is represented as “all bits zero” and is the smallest possible value of the range of values it can have.

Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
  • I do not see how the concept of normalization even applies to zeroes. So in my thinking (25 years experience building IEEE-754 based libraries and processors), zeroes are neither normalized nor denormalized. I would thus put them in their own category. – njuffa Mar 23 '15 at 17:02
  • @njuffa: In systems which can accommodate floating-point values without an "implied 1", positive and negative zeroes are simply values whose mantissa is zero but which are otherwise unexceptional. Some systems cannot accommodate any floating-point value without an "implied 1", and in those systems it's necessary to have special handling for zero. – supercat Mar 24 '15 at 22:11
  • @supercat: I have worked with IEEE-754 formats with and without implied leading "1" for the mantissa, VAX floating-point format, Microsoft floating-point format, Turbo-Pascal floating-point format, etc. As far as I can recall, in none of these does the notion of normalization make any sense when applied to zero(es), there simply is nothing there in zero operands that could be normalized or denormalized. – njuffa Mar 24 '15 at 22:21
  • @njuffa: In formats without a leading "1", a zero mantissa would imply a zero value. In IEEE-754 single- and double-precision formats, there is only one exponent value for which a leading "1" is not required, which in turn implies that there is only one positive zero and one negative zero. If a system uses something like 80-bit format (no implied leading "1") and lazily normalizes values after addition/subtraction (if a processor with slow shifting instructions is computing 16777219-16777218+16777217, normalizing the first difference would not only waste time, but would... – supercat Mar 24 '15 at 22:30
  • ...make the second addition slower as well), then there would be 65,534 different "zero" values, but there would only be one "normalized" positive zero and one negative zero. Code could benefit from special-casing zero (as opposed to just shifting left and subtracting one from the exponent until either the MSB was set or the exponent reached minimum) but I don't think such special treatment would be required for correctness. – supercat Mar 24 '15 at 22:32
  • There are "pseudo-zero" encodings in the 80-bit x87 "extended" format (i.e. matissa/significand is all zero bits, but exponent is different from zero), is that what you are referring to? Since the mantissa/significand pattern for "true zeroes" and all "pseudo zeroes" consists of all zero bits, normalization still doesn't seem to come into play. – njuffa Mar 24 '15 at 22:47
  • Thanks everyone for their input, it turns out that I was right, and the professor just made a small error. :) – Rafi Mar 25 '15 at 23:48
  • If zero is not denormal, then here [Why does changing 0.1f to 0 slow down performance by 10x?](https://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x) – dashesy Sep 25 '17 at 22:59
  • 1
    @dashesy I have no idea what this comment two years after the question was asked and answered is trying to achieve. Surely you did not read the answer as taking a strong stance that zero should be considered denormal? If you are addressing others who might adopt such a stance, this is a terrible place to put your message to them: they, unlike me, won't be notified of it. – Pascal Cuoq Sep 26 '17 at 09:01
  • @dashesy your argument is not terribly convincing. Whether zero is denormal or not is an intrinsic property that has nothing to do with the details of some implementations out there. An implementation could decide to make multiplication by 2 faster than multiplication by 3 and that would not make 3 denormal. – Pascal Cuoq Sep 26 '17 at 09:04
  • @PascalCuoq I am just curious. Practically, I would like to know if I should consider changing `+ 0.0` to `+ eps` if/when I have a weight matrix addition. I think many systems never consider this . Reading about [IEEE standard](http://steve.hollasch.net/cgindex/coding/ieeefloat.html) also suggests that zero is denormal, but I am not yet fully satisfied by it because that would make zero less useful. – dashesy Sep 26 '17 at 17:01