Interesting article on Cleve's corner today:

http://blogs.mathworks.com/cleve/

On floating points issue and his analysis why it happened.

But wanted to show here that doing the same thing using a CAS
removed the problem (as would be expected, nothing surprising,
since using pure integers). Ofcourse one can argue about speed
and performance in real large numerical problems and all of this.

But I just thought some here might like to see it.

It is finding the Determinant of 2 by 2 matrix of integers.
The correct answer is 1.

I tried the example shown on some software I have, here is
the result. I run in on matlab 2112a,matlab 2112a/symbolic,octave,
Mathematica,Maple:

---- matlab 2112a --------------
EDU>> X = [  63245986, 102334155
        102334155, 165580141];

EDU>> det(X)

      1.5249

---- matlab 2112a/Symbolic -------------
EDU>> syms X
EDU>> X=sym([ 63245986, 102334155;102334155, 165580141])

[  63245986, 102334155]
[ 102334155, 165580141]

EDU>> det(X)

1

----- GNU Octave, version 3.2.4 on Linux -------
octave:3> X
X =
      63245986   102334155
     102334155   165580141

octave:4> det(X)
ans =  0.99950

---- Mathematica 8.04------
Clear["Global`*"];
a=63245986; b=102334155; c=102334155;d=165580141;
mat={{a,b},{ c,d}};
Det[mat]

     Out[25]= 1

--------Maple 14-----------

with(LinearAlgebra):
M:=Matrix([[63245986,102334155],[102334155,165580141]]);
                                [ 63245986    102334155]
                           M := [                      ]
                                [102334155    165580141]

Determinant(M);
                                         1
----------------------------

But before we go celebrate, justed wanted to point that even the
CAS programs do not generate 1 when the numbers are made to be
floating points. Interesting also to see now the results:

---- Mathematica 8.04------
Clear["Global`*"];
a=63245986.;b=102334155.;c=102334155.;d=165580141.;
mat={{a,b},{c,d}};
Det[mat]

     Out[22]= 1.5249

--------Maple 14-----------

---------------------------

Mathematica result now agrees with Matlab's. I am not sure
why Maple gives zero. May be I need to use an option somewhere
for the Matrix construtor. Not a Maple expert.

I guess it is true then that God made the integers and the
rest is the work of man :)

x: matrix([  63245986, 102334155],[       102334155, 165580141]);

makelist(determinant(bfloat(x)),fpprec,10,20);

[0.0b0,0.0b0,0.0b0,0.0b0,0.0b0,0.0b0,1.0b0,1.0b0,1.0b0,1.0b0,1.0b0]

The correct value in double precision round nearest
would be 2.0, while in long double it would be 1.0,
thus that is strange.

For Maple you have to set Digits - else only 10 are
used and det = a*d - b*c subtracts two floats, which
have a length of 17 each, so this results in float(0),
as they differ only in the last place.

For MMA I do not know, especially how it increases
working precision after input.

Here is another one, due to Kahan:

a = 2017810 * 8264001469,
b = 39213 * 229699315399,
c = 45077 * 107932908389

But I find this whole thing annoying sometimes
when one 'types' in integers into these packages but
because everything is done in floating point, (1 is 1.0 in
Matlab ofcourse) one ends up losing accuracy compared to
using CAS when 1 is really 1 and not 1.0

Here is a small example. Cross correlation between 2
sequences of integers:

---------- Mathematica ------------------
a={0,0,2,-1,3,7,1,2,-3,0,0};
b={0,0,1,-1,2,-2,4,1,-2,5,0,0};
c=Reverse[ListCorrelate[a,b,{-1,1},0]]

Out[31]= {0,
           0,
           0,
           0,
           10,
           -9,
           19,
           36,
           -14,
           33,
           0,
           7,
           13,
           -18,
           16,
           -7,
           5,
           -3,
           0,
           0,
           0,
           0}

Matlab
-------------
A=[0,0,2,-1,3,7,1,2,-3,0,0];
B=[0,0,1,-1,2,-2,4,1,-2,5,0,0];
C=xcorr(A,B);
format long
C'

ans =

    0.000000000000003
    0.000000000000002
   -0.000000000000002
                    0
    9.999999999999998
   -9.000000000000002
   19.000000000000000
   36.000000000000000
  -14.000000000000000
   33.000000000000000
   -0.000000000000002
    6.999999999999998
   13.000000000000000
  -18.000000000000000
   16.000000000000004
   -7.000000000000000
    4.999999999999999
   -2.999999999999998
   -0.000000000000000
    0.000000000000001
    0.000000000000002
   -0.000000000000004
                    0

These small difference can carry on to other computations ofcourse
causing more losses of accuracy.

May be one day, when computers become really fast and
has lots more memory, one can do things like computational
fluid dynamics and weather forecasting computation using nothing
but exact rational arithmetic. No more floating points!

May be in 100 years from now?

Or may be I am just dreaming here.

If what annoys you is the binary <--> decimal conversion, you could find
a system that does decimal arithmetic (still, floating-point).

If what annoys you is the introduction of error, you could find a system
that did interval arithmetic  (maybe 8X slower, and 2X the memory).
Or use Mathematica's software floats that try to do something similar
(significance arithmetic).  I'm not a fan of that, however.

Or you could use programs that have been cleverly written to include
  extra computations to estimate errors (maybe 2X slower)

Or you could wait 100 years and see what comes up...