Re: 32-bit IEEE float multiplication
"Dik T. Winter" wrote:[color=blue]
>
> In article <aed59298.03120 40655.43db93e4@ posting.google. com> bikejog@hotmail .com (Andy) writes:[color=green]
> > But here's a real question, given the code below
> >
> > unsigned long ticks = 0; /* 32-bit */
> > float fVal; /* 32-bit IEEE-754 */
> >
> > while(++ticks) {
> > fVal = (float)ticks * 0.004;
> > }
> >[/color]
> [...]
> Another problem with your code is that when ticks exceeds 2**24 the
> number is no longer exactly represenatable as a floating point number,
> so all bets are off.[/color]
Not "all" bets, but it certainly scuttles any hope of
strict monotonicity.
Here's the scenario: `ticks' counts up to a large power
of two, about 2**24 or 2**25 (I'd have to pull out my IEEE
reference to be sure of the value, but the exact location
of this boundary isn't essential to understanding the effect).
Up to this point, the expression `(float)ticks' has produced
an exact conversion: the result is exactly equal to the
original value of `ticks'.
But at the next upward count a problem arises: `ticks'
now has one more significant bit than a `float' can handle.
(Imagine counting upwards in decimal arithmetic with three
significant digits: 999 is fine, 1000==1e3 is fine, but
1001 has too many digits.) So the conversion is inexact,
and if "round to even" is in effect the result will be a
hair too small -- in fact, it will be the same result as was
obtained from the preceding exact conversion. That is, `ticks'
increased but `(float)ticks' did not.
On the next count, the problem disappears momentarily:
the low-order bit of `ticks' is now a zero, so the number of
significant bits is once again within the capacity of `float'.
The conversion is again exact -- but look what's happened: the
value `(float)ticks' has advanced two steps at once. You've
entered a regime where `(float)ticks' "sticks" at one value
for two ticks before advancing to the correct result; it
"increments every other time."
As you go higher still, `ticks' will eventually attain
two more significant bits than a `float' can handle, and
will "stick" at one value for four cycles before increasing.
And then you'll get to three bits too many and an eight-
cycle plateau, and so on. (Consider the decimal analogy
again: after you reach 1000000==100e4, you've got to count
upward many more times before reaching 101e4==1010000. )
However, the cure for your case seems obvious: Whether
you know it or not, you're actually employing `double'
arithmetic in this expression because the constant `0.004'
has type `double'. So why convert to `float', losing a few
bits in the process, only to go ahead and re-convert that
mangled value to a `double'? Just make `fVal' a `double'
to begin with and get rid of the `(float)' cast, and you
should be immune to this effect.
There may be other problems elsewhere, of course, but
this problem, at least, will cease to bother you.
--
Eric.Sosman@sun .com
"Dik T. Winter" wrote:[color=blue]
>
> In article <aed59298.03120 40655.43db93e4@ posting.google. com> bikejog@hotmail .com (Andy) writes:[color=green]
> > But here's a real question, given the code below
> >
> > unsigned long ticks = 0; /* 32-bit */
> > float fVal; /* 32-bit IEEE-754 */
> >
> > while(++ticks) {
> > fVal = (float)ticks * 0.004;
> > }
> >[/color]
> [...]
> Another problem with your code is that when ticks exceeds 2**24 the
> number is no longer exactly represenatable as a floating point number,
> so all bets are off.[/color]
Not "all" bets, but it certainly scuttles any hope of
strict monotonicity.
Here's the scenario: `ticks' counts up to a large power
of two, about 2**24 or 2**25 (I'd have to pull out my IEEE
reference to be sure of the value, but the exact location
of this boundary isn't essential to understanding the effect).
Up to this point, the expression `(float)ticks' has produced
an exact conversion: the result is exactly equal to the
original value of `ticks'.
But at the next upward count a problem arises: `ticks'
now has one more significant bit than a `float' can handle.
(Imagine counting upwards in decimal arithmetic with three
significant digits: 999 is fine, 1000==1e3 is fine, but
1001 has too many digits.) So the conversion is inexact,
and if "round to even" is in effect the result will be a
hair too small -- in fact, it will be the same result as was
obtained from the preceding exact conversion. That is, `ticks'
increased but `(float)ticks' did not.
On the next count, the problem disappears momentarily:
the low-order bit of `ticks' is now a zero, so the number of
significant bits is once again within the capacity of `float'.
The conversion is again exact -- but look what's happened: the
value `(float)ticks' has advanced two steps at once. You've
entered a regime where `(float)ticks' "sticks" at one value
for two ticks before advancing to the correct result; it
"increments every other time."
As you go higher still, `ticks' will eventually attain
two more significant bits than a `float' can handle, and
will "stick" at one value for four cycles before increasing.
And then you'll get to three bits too many and an eight-
cycle plateau, and so on. (Consider the decimal analogy
again: after you reach 1000000==100e4, you've got to count
upward many more times before reaching 101e4==1010000. )
However, the cure for your case seems obvious: Whether
you know it or not, you're actually employing `double'
arithmetic in this expression because the constant `0.004'
has type `double'. So why convert to `float', losing a few
bits in the process, only to go ahead and re-convert that
mangled value to a `double'? Just make `fVal' a `double'
to begin with and get rid of the `(float)' cast, and you
should be immune to this effect.
There may be other problems elsewhere, of course, but
this problem, at least, will cease to bother you.
--
Eric.Sosman@sun .com
Comment