- From: <zongaro@ca.ibm.com>
- Date: Thu, 24 Jan 2002 10:15:01 -0500
- To: Dave Peterson <davep@acm.org>
- Cc: www-xml-schema-comments@w3.org, cmsmcq@acm.org, ashokma@microsoft.com, Paul.V.Biron@kp.org
- Message-ID: <OF7FAB40E4.FE7B8604-ON85256B4B.004E9C73@torolab.ibm.com>
Hi Dave,
A small quibble: the greatest, finite float value really is 2**128 -
2**104. Although IEEE 754 allows only 23 bits for the significand, one
bit for the sign, and eight for the exponent, all normalized values have
an implied MSB with a value of one. That means the significand (m) runs
from 2**23 to 2**24-1. Hence, the greatest, finite value really is
(2**24-1)*2**104 or 2**128-2**104.
You also wrote that:
[[
> I just noticed another problem with the specification of how
>lexical values map to float values in the value space. The text
>cited above assumes that, of two consecutive normalized values in
>the value space, one will be even and the other will be odd.
Yet another example of not-quite-precise writing, I'm afraid. We copied
from Clinger who copied from (I assume) 754. Something got lost in
translation. (Ever play the gossip game?)
Note how each representable number has precisely one representation.
(I'll leave it to you to check the details about subnormalized numbers--
what I'm about to say is for positive normalized.)
One representable number and the next each have a particular m value;
usually with the same e, but at the boundary one m is all 1 bits; the
next up (larger e) is all 0 bits except the top-most bit. In the first
case, the higher m is 1 more than the lower, so one number's m is odd
and the other's is even; in the second case, the lower is necessarily
odd and the next is even. It's the even-ness of the integer m (the
"radicand", incorrectly called the "mantissa") that decides, not that
of the number represented.
]]
I agree that IEEE 754 allows for only one representation of each
finite value - it's true of both normalized and subnormalized values. My
concern was with 3.2.4 of Datatypes, which states that the value space
consists of the values "m*2^e, where m is an integer whose absolute value
is less than 2^24, and e is an integer between -149 and 104." The
existing description allows for more than one way of expressing most
values, and hence it would be impossible to use the fact that m is odd or
even to determine the direction for rounding with the existing description
of the value space. A description that limited m to the range
[2**23,2**24-1], as you've described below, is necessary.
As long as we're on the topic of subnormalized numbers, it's not
clear to me whether they were intended to be part of the value space. The
description of the value space I've quoted above admits the subnormalized
values to the value space - they are those values for which e=-149 and 0 <
m < 2**23. However, literals in the lexical space map to the closest
*normalized* value. That would mean that there are values in the value
space to which no value in the lexical space will map. Any revision of
the description of float needs to answer this question.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro XML Parsers development
IBM SWS Toronto Lab Tie Line 969-6044; Phone (905) 413-6044
mailto:zongaro@ca.ibm.com
To: Henry Zongaro/Toronto/IBM@IBMCA, www-xml-schema-comments@w3.org
cc: cmsmcq@acm.org, ashokma@microsoft.com, Paul.V.Biron@kp.org
Subject: Re: largest finite float
At 4:58 PM -0500 1/23/02, zongaro@ca.ibm.com wrote:
>C.M. Sperberg-McQueen wrote:
>[[
>The largest finite float, if I understand the notes correctly, is
>
> m * 2**e
>
>where ** means exponentiation,
> m is the largest number representable in the mantissa, and
> e is the largest number representable as an exponent
[TERMINOLOGY NOTE: m in this representation is *not* properly called the
mantissa. "Significand" is better.]
>Since we have
>
> m = 2 ** 24 - 1
> e = 127
>
>it follows that
>
> m * 2**e = (2**24) * (2**127) - 2**127
> = 2**151 - 2**127
>
>]]
>
>A small correction here - the maximum value of e in that formula is
>actually 104 (the minimum value is -149), so I believe the largest
>finite float value is 2^128 - 2^104, which is approximately
>3.4028x10^38. (I'll refer to it as M below.)
Almost. Depending on how old that paper of mine was--there was a time
when
I was confused about how 754 approached this matter.
o For float, one uses 8 bits for e and 24 for m.
o For "normalized" numbers, the top bit of m is on.
o For normalized *positive* numbers, (since one bit is m's
sign bit,
there are 23 left), this means
o -127 <= e <= 127
(All bits on, -128, is reserved for signalling NaNs
and
infinities.)
o 2*22 <= m <= 2*23 - 1
o For e = 0, this would result in normalized positive
numbers of the
form m * 2**e running from 2**22 to 2**23 - 1 . Then
varying e
equally on either side of 0 would bias things heavily in
favor of
large numbers.
o What they want is, for exponent zero, to have numbers
close to and
just less than 1. This requires that you bias the
exponent by -23.
o This means the number represented by m and e is (m * 2**e
* 2**-23)
Therefore the largest number representable is
(2**23 - 1) * 2**127 * 2**-23
which is
(2**23 - 1) * 2**104, AKA (2**127 - 2**104)
Net result is that Michael (and undoubtably me, back then) didn't bias the
exponent--and Michael, me back then, and Henry all failed to account for
the sign bit. I leave it to those with time and calculator packages to
work out the decimal representation.
Henry continued, again quoting Michael:
>[[
>Some things are, unfortunately, not so clear to me:
>
> (a) what the next largest float would be if we had one
> (b) where the watershed point is between infinity and 2.85...E45
> (c) whether the negative numbers are exactly the same as these
> plus a minus sign, or divergent in some way
>
>I don't believe there has been any confusion over the watershed
>between zero and the smallest representable float.
>
>Dave, if you can confirm that I have correctly interpreted your
>notes, I'd be grateful. Ditto if anyone can shed light on questions
>(a), (b), (c) above.
>]]
>
> Regarding question (a), I'm not sure if there is a sensible
>answer to that. To have a next larger finite float value, you'd
>have to have either more bits in the mantissa or more bits in the
>exponent - which you choose determines what would be the next larger
>float value.
Because of the bias, if you add more bits to the m (sorry, but it ain't a
mantissa) you also increase the bias, no net gain. To get larger numbers
you must increase the exponent's bits. Therefore, the next larger number
would be
(2**22) * 2**(127 + 1) * 2**-23, AKA (2**127)
>[[
>A literal in the
><http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dt-lexical-space>·lexical
>space· representing a decimal number d maps to the normalized value
>in the
><http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dt-value-space>·value
>space· of float that is closest to d in the sense defined by
><http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#clinger1990>[Clinger,
>WD (1990)]; if d is exactly halfway between two such values then the
>even value is chosen.
>]]
>
> A literal reading of that text would have any lexical value
>representing a decimal number greater than M map to M, because
>that's the closest normalized value in the value space. So, for
>instance, 1.0E+100000 would map to M. I believe that behaviour
>would be contrary to the expectations of most users.
Quite so. If I understand 754 correctly, the round-off algorithm is first
described in an "arbitrary integer exponent" model (i.e., as large an
exponent as you need, for this case). So, for a given number of bits for
the m, every scientific-decimal numeral maps to some number by the
algorithm.
If that number requires a larger integer exponent than is available, then
it is forcibly mapped to infinity. So just as the cutoff between the last
two representable numbers is half-way between the two, for rounding
purposes,
the cutoff above the last representable number is half way between that
number and the "next" one that would be representable with a larger
exponent.
For float, that means half way between 2**127 - 2**104 and 2**127.
> I just noticed another problem with the specification of how
>lexical values map to float values in the value space. The text
>cited above assumes that, of two consecutive normalized values in
>the value space, one will be even and the other will be odd.
Yet another example of not-quite-precise writing, I'm afraid. We copied
from Clinger who copied from (I assume) 754. Something got lost in
translation. (Ever play the gossip game?)
Note how each representable number has precisely one representation.
(I'll leave it to you to check the details about subnormalized numbers--
what I'm about to say is for positive normalized.)
One representable number and the next each have a particular m value;
usually with the same e, but at the boundary one m is all 1 bits; the
next up (larger e) is all 0 bits except the top-most bit. In the first
case, the higher m is 1 more than the lower, so one number's m is odd
and the other's is even; in the second case, the lower is necessarily
odd and the next is even. It's the even-ness of the integer m (the
"radicand", incorrectly called the "mantissa") that decides, not that
of the number represented.
Hope this all helps. Michael, I'm too tired to check out negatives.
I'm pretty sure they're symmetric. I can't imagine any reason they
wouldn't be.
--
Dave Peterson
SGMLWorks!
davep@acm.org
Received on Thursday, 24 January 2002 10:15:21 UTC