interesting case where CAS computation makes a large numerical difference

[Nasser M. Abbasi]

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-----------

> with(LinearAlgebra):
> M:=Matrix([[63245986.0,102334155.0],[102334155.0,165580141.0]]);
[ 8 9]
[0.632459860 10 0.1023341550 10 ]
M := [ ]
[ 9 9]
[0.1023341550 10 0.1655801410 10 ]

> Determinant(M);
0.

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

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 :)

--Nasser

[Richard Fateman]

On 6/7/2012 5:09 PM, Nasser M. Abbasi wrote:
>

>

in maxima, using floating precisions from 10 to 20...

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]

determinant(float(x)) comes out 2. while
determinant(x) comes out 1
as expected.

[Axel Vogt]

On 08.06.2012 02:09, Nasser M. Abbasi wrote:
>
> Interesting article on Cleve's corner today:
> http://blogs.mathworks.com/cleve/
>
> On floating points issue and his analysis why it happened.

...

> ---- matlab 2112a --------------
> EDU>> X = [ 63245986, 102334155
> 102334155, 165580141];
>
> EDU>> det(X)
>
> 1.5249

...

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

and now b^2 - a*c (or write as matrix & determinant):
check for 0 or for sign using floats (double precison).

[Nasser M. Abbasi]

On 6/8/2012 2:47 PM, Axel Vogt wrote:
> On 08.06.2012 02:09, Nasser M. Abbasi wrote:
>>
>> Interesting article on Cleve's corner today:
>> http://blogs.mathworks.com/cleve/
>>
>> On floating points issue and his analysis why it happened.
> ...
>> ---- matlab 2112a --------------
>> EDU>> X = [ 63245986, 102334155
>> 102334155, 165580141];
>>
>> EDU>> det(X)
>>
>> 1.5249
> ...
>

> 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.
>

I do not know. Matlab uses double by default. I never
heared of long double in Matlab.

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.

--Nasser

[Richard Fateman]

On 6/8/2012 9:16 PM, Nasser M. Abbasi wrote:
>
> 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?

It is generally believed that the size of the individual rational number
numerators and denominators would grow exponentially with the number
of operations, increasing the cost of the operations, the memory, and
the output display. Considering that the input data is unlikely to be
exact (from physical measurements) this approach would probably be
mostly pointless.

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...

RJF