Re: Problem in Float Arithmetic

Tech-Archive recommends: Fix windows errors by optimizing your registry

ASSERT((double)((int)f1 / (int)f2) == (f1 / f2));

This is true only if f1 is an integer multiple of f2. If f1 is not an integer multiple of
f2, then we get into the floating-point-is-not-exact morass.
joe

On Sat, 05 Jul 2008 16:22:31 -0500, "Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote:

On Sat, 05 Jul 2008 14:34:30 -0400, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:

When integers and integers only are represented as doubles, and the operations are limited
to add, subtract, and multiply, then the precision of a double is the same as the
precision of an integer of the same number of bits of significance as the mantissa of the
floating point number. The problem, for example, is that 'float' has fewer bits than
'int', so it only becomes interesting when you start using 'double'.

Right, I couldn't imagine using anything but double for this. However, if
int was 16 bits, the usual 32 bit float could work (23 bit mantissa), but
it would almost certainly be better to use long, which has at least 32
bits. The only exception I can think of is some weird hardware that has a
fast FPU but a really lousy ALU that can't do 32 bit integers.

Once "divide" comes into play, life gets very dicey even if the only values are initially
integral.
joe

What I said to David was:

<q>
Floating point arithmetic on integer values that produces integer values is
exact over a wide range, something like +/- 2^53 for double.
</q>

I did not mean anything but exactly what I wrote. Are you saying it's not
true for division? (If not, too bad for languages like Perl, I guess.)
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages