dgges issue

[OndraKamenik]

All,

I have the following problem with dgges. For version 3.1.1 and sooner, I get a reasonable result, for version 3.2 and 3.2.1 I get info=n+2.

I am separating eigenvalues in the unit circle from one outside the unique circle.

The two D and E matrices have relatively well separated null spaces, the minimum angle is acos(0.97). However, if i calculate condition numbers of E-lambda*D of lambda=[-1:0.01:1], they are quite bad.

The matrices are attached with a small c++ program which calls dgges and sorts eigenvalues for a better comparison. There is also a Makefile, which links with different version of lapack.

I use the reference blas.

My question is if it is a bug in Lapack introduced between 3.2. and 3.1.1 or the matrix is just very bad and in version 3.1.1 I was just lucky to get a reasonable solution.

Many thanks for any help.

Ondra Kamenik

[admin]

Yes, I believe you have the correct guess:

* Note that in the ill-conditioned case, a selected complex
* eigenvalue may no longer satisfy SELCTG(ALPHAR(j),ALPHAI(j),
* BETA(j)) = .TRUE. after ordering. INFO is to be set to N+2
* in this case.

And from some commits done between 3.1.1 and 3.2

Harden xLASCL against infinite and NaN inputs.

xLASCL will fall into an infinite loop with infinite and NaN inputs.
While those inputs *should* never happen, the code should terminate
if they do.

Julie

[OndraKamenik]

Julie,

many thanks for your response.

I analyzed the differences between 3.2 and 3.1.1 and found out that if I replace dgeqr2 in 3.2 with one from 3.1.1, everything works. The only difference in dgeqr2.f is that 3.1.1 version calls dlarfG and 3.2 version calls dlarfP.

Of course I don't know what is the difference and what were the reasons for the change, but I would really appreciate if you could explain or even rethink the change. Perhaps dlarfp has some little little little flaws? Ok, ok, ok, I dared too much. (I am pretty unaware about this stuff).

I admit that in my both examples, the generalized eigenvalues don't have satisfactory condition numbers, and my second example has even very small angle between null spaces of the two matrices. But my experience so far (version 3.1.1 and earlier) was that the backward errors estimates implied by condition numbers were too pesimistic and the problems (economic models) were stable for small perturbations.

many thanks again,

Ondra Kamenik

[Julien Langou]

Dear Ondra,
Yes, Julie came to the same conclusion as you this morning. She emailed it to me: "If we change the calls of DGEQR2 from DLARFP to the original DLARFG, then everything works fine." DLARFP has been introduced in 3.2.0 and we know it's buggy. And we are currently still debugging it. So yes we had big suspicion on this routine from the start. I have a slightly better version that Julie will try later today. There is still some problem. I might advocate to reverse all LAPACK to DLARFG until DLARFP works. I am thinking about this.
Best wishes, Thanks a lot for all the work,
You are the first user to really have been hit by a problem with this routine. Sorry about this.
Julien.

More information: http://www.netlib.org/lapack/Errata/ : bug0037 (we need to link bug0048 on it)

[OndraKamenik]

Julien,

this is a very good news.

I have been flying across many timezones recently and this problem was not helping me to fall asleep when I needed. Now having the problem pinned down, there is a chance I would be back on tracks also with my sleep.

cheers,

Ondra Kamenik

[Julien Langou]

The bug was indeed tricky. Guillaume Revy and Jim Demmel (UC Berkeley) spent a while tracking this down. I have committed their fix in the lapack repository (revision 735). Please check this out and let us know. Now everything works fine on our machine. Thanks a lot for the bug report. Best wishes, Julien.

[molenno]

I have the same problem...

[admin]

Hi,
You can access the LAPACK SVN repository that contains the fix.
See http://www.netlib.org/lapack/#_svn_access
We will release very soon a bug-fix version of LAPACK.
Stay tuned!
Julie