This is an interesting example. It goes to the heart of the issue when computes with floating point arithmetic. First consider this
>> theta=0.589048622548086;
>> e0=[-1i*cos(theta/2),0,0,sin(theta/2)];
>> A=e0'*e0;
>> eig(A)
ans =
0
0
1.3878e-17
1.0000e+00
Clearly there is some mistake here. Matrix A should only have rank 1. But MATLAB thinks that it has rank 2. And it is the small nonzero eigenvalues that is causing the problem.
>> sqrt(1.3878e-17)
ans =
3.7253e-09
Has EIG gone dotty? Hardly, it is trying its very best. Let double check the result using symbolic toolbox.
>> sA = sym(A,'f')
sA =
[ 8248205863506131/9007199254740992, 0, 0, 5004131788810439i/18014398509481984]
[ 0, 0, 0, 0]
[ 0, 0, 0, 0]
[ -5004131788810439i/18014398509481984, 0, 0, 379496695617431/4503599627370496]
>> double(eig(sA))
ans =
0
0
7.7070e-18
1.0000e+00
Better but still rank 2. So one can conclude that the problem exists in Symbolic Toolbox too. Maybe, but this is not the root cause. What I did not say was that I told Symbolic Toolbox to treat A as exact, and that assumption was wrong. Matrix A was not the "A" that you think it is. It is a very good approximation of the real thing. To see this, use symbolic calculation to form A.
>> theta= sym(0.589048622548086)
theta =
(3*pi)/16
>> e0=[-1i*cos(theta/2),0,0,sin(theta/2)];
>> A=e0'*e0
A =
[ cos((3*pi)/32)^2, 0, 0, cos((3*pi)/32)*sin((3*pi)/32)*1i]
[ 0, 0, 0, 0]
[ 0, 0, 0, 0]
[ -cos((3*pi)/32)*sin((3*pi)/32)*1i, 0, 0, sin((3*pi)/32)^2]
>> double(eig(A))
ans =
0
0
0
1
Yes, rank 1 as expected. But wait, can use this to form a better A? Maybe, but no guarantee. On my computer,
>> eig(double(A))
ans =
0
0
1.3878e-17
1.0000e+00
This is a true limitation of floating point arithmetic. By the time SQRTM sees A, it is too late.
0 Comments
Sign in to comment.