"John Randall" <[EMAIL PROTECTED]> wrote:
> - Computer integers exactly represent mathematical integers, within
> limits: floating-point numbers represent almost no real numbers
> exactly.
>
> - Integer arithmetic is exact, floating-point arithmetic is not.
Actually, this is not exactly true.
The hardware represents integers exactly, and it represents floating-point
values exactly. The arithmetic is also exact:
2 + 3 -> 5
2.0 + 3.0 -> 5.0
What happens, however, when the values go outside of the domains
in which exact arithmetic is posible, thye behave differently.
For interpolation, integers truncate, while floats approximate:
10 % 3 -> 3
10.0 % 3.0 -> 3.333333333
For extrapolation, integers overflow, while floats become infinite:
*: 65535 -> _131071
*: 1.0e200 -> _
When we see a floating-point number, unless we know for a fact
that it was the result of an exact calculation, we usually assume
that it is merely an approximation to within one half of a LSB of
the machine precision.
> - Figuring out how to calculate mathematical functions accurate to 1
> ulp is not easy: for example. no-one knows how many guard digits
> are needed to calculate x^y over the full range of floating-point
> numbers.
If x is an exact floating-point number (in the form a*2^b for integers a,b)
and y is an integer, this could be calculated fairly easily. For other
values,
> - Neglecting overflow, integer addition and multiplication mirror
> their mathematical counterparts. Floating-point addition is not
> commutative and associative.
Floating-point addition IS associative if you are dealing with exact
values.
(2.0 + 3.0) + 4.0 <-> 2.0 + (3.0 + 4.0)
This only breaks down if any of the operations create inexact results;
in this case, the addition does not distribute over the implicit error.
(Unfortunately, this is the general case for data whose source is
not predictable.)
If you store integers within floating-point values,
however, since floating-point precision exceeds [32-bit] integer
precision, any floating-point caltulation using integer values will
produce exactly the same result as the corresponding integer calculation:
In C, for all integers a and b (which do not produce integer overflow)
(double) (a+b) == (double) a + (double) b;
> - It is nontrivial to devise algorithms that give acceptably accurate
> results reasonably quickly while working to a fixed maximum precision.
Yes, very true.
Dan Bron <[EMAIL PROTECTED]> wrote:
> I know there a huge differences between int and flop math, but intuitively I
> cannot understand __why__.
>
> Why should it be that flop + is not associative? If we know precisely how
> many
> digits req'd for arbitary-length int ^ , why is it not so for flop ^ ?
> Why is the
> singles-decimal place in a 6-digit int more important than the
> hundred-thousandths
> decimal place in a flop between 1 and 10? Why is it easier to preserve?
> Where is the magic hiding?
Floating-point values are exact, but they often represent inexact results of
other calculations.
Let's assume a fictitious machine with a 3-digit decimal floating-point unit:
(1e0 + 5e_3) + 5e_3 -> 1e0 + 5e3 -> 1.00
1e0 + (5e_3 + 5e_3) -> 1e0 + 1e_2 -> 1.01
In the first case, each + suffers precision loss, which does not happen in the
second case.
For x^y, the precision is easy to compute when y is an integer. With integer
arithmetic,
this is always the case. However, for floating point, it is not. Even x^0.5
requires an
infinite number of digits for all x that are not perfect squares.
-- Mark D. Niemiec <[EMAIL PROTECTED]>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
