The routine was returning with INFO = 0 while a failure of convergence should
have been reported with INFO > 0.
The bug has been around for quite a while and has been difficult to reproduce.
More information:
(*) bug0025 :: serious problem in DGESDD: DGESDD returns negative singular values with INFO = 0
o reported by Guy Bencteux on Sat Dec 06 2008
o see forum topic 847
o Julie : CANNOT REPRODUCE THE PROBLEM
o on Sat Jun 19 2010, Bruno Pinçon from ESIAL, reported another matrix with the same problems
o see forum topic 1868
o we can reproduce the problem with on MacOS with gfortran reference LAPACK
and vecLib BLAS, we can not reproduce the problem with reference LAPACK and reference BLAS.
o A patch has been proposed by Julien Langou. (See forum topic 1868.)
o Under review by other lapackers.
o Note: there is strong evidence that the bug of Guy Bencteux and this one
are the same, although we were never able to reproduce Guy's problem. So
we assume Guy's problem gone! (And send an email to Guy to inform him.)
Add SYCONV routine: convert back and forth the factorization returned by SYTRF to be able to call SYTRS2.
Modify SYSV that now is calling SYTRS2 instead of SYTRS (and also SYCONV to convert and revert the factorization returned by SYTRF).
Modify testing to have TRS but also TRS2 tested in the LIN testing for SY.
The bug report and bug fix are from William Gandler (NIH/CIT). The related
emails are on the mailing list dated as follows: October 16, 2009; April 23,
2010; May 01, 2010, May 03, 2010.
I was just looking at zgbsvxx.f from LAPACK 3.2.1 and I noticed a small
mistake in some of the argument descriptions. AB, AFB, B and X are all
down as DOUBLE PRECISION rather than COMPLEX*16.
Issue in LAPACK 3.2.1 *la_{po,sy,he}rfsx_extended.f sources. For instanse, in sla_syrfsx_extended.f:
DY is described as
* DY (input) REAL array, dimension (N)
* Workspace to hold the intermediate solution.
whereas N-by-NRHS array is referenced at DY due to the following statement (line 384):
CALL SSYTRS( UPLO, N, NRHS, AF, LDAF, IPIV, DY, N, INFO )
This may lead to an outside memory corruption. I assume one RHS should be referenced here, because all the RHSs are considered individually in the loop by J. That is, substituting NRHS by 1:
CALL SSYTRS( UPLO, N, 1, AF, LDAF, IPIV, DY, N, INFO )
should fix the issue. This is actual for any subroutine mentioned.
"Bug" reported by Ondra Kamenik, confirmed by Julie Langou, fixed by Jim Demmel
and Guillaume Revy. See forum post 1783.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Fix problem in xTGEX2. The threshold value is too stringent and some matrices
are failing. Relax the threshold by a factor 2. More below.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
See: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1783
dgges issue >> by OndraKamenik >> Tue Mar 16, 2010 6:01 am
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
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Much more conversation on mailing list and forum [ skipped ]
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Date: Wed, 31 Mar 2010 19:53:11 -0600
From: James Demmel
This bug was introduced by changing the routine that computes Householder
transformations in the last release of LAPACK from dlarfg to the new dlarfp,
which makes the diagonal of the R factor in QR nonnegative. The bug was a
failure (INFO = N+3) in the dgges routine for computing selected deflating
subspaces of a matrix pencil A - lambda*B. I will describe the bug, a quick
fix, and implications for the floating point debugging project that Guillaume
and others of us are working on.
The bug occurred in dtgex2, in the swapping of eigenvalues (adjacent 1x1 and/or
2x2 blocks on the diagonal of the generalized Schur form) in order to compute
a selected subspace. The swapping involves QR decompositions of small (n <= 4)
matrices.
The code in dtgex2 performs two of its own internal correctness tests (a "weak"
one and a "strong" one) to see if the swapping has been performed stably. The
two tests compute a residual in slightly different ways. The weak test passed,
but the strong test (which can be commented out by setting the internal
parameter WANDS to be .false.) failed, leading to returning INFO = N+3.
However, it failed by exceeding the threshold THRESH only by a factor like 1.2
or less. THRESH is set to 10*macheps*dnorm, so if we changed the (probably
somewhat arbitrary) factor from 10 to 20, it would work. Or we could set WANDS
= false.
Since Bo's name is on this routine, his comments are particularly welcome.
Guillaume and I spent a while tracking this down, and will continue to find out
why dlarfp led to a (slightly!) larger residual than the old dlarfg.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Date: Thu, 1 Apr 2010 20:01:21 -0600
From: James Demmel <demmel@cs.berkeley.edu>
Actually, on reexamining the data, this example would be fixed by
changing 10 to 11,
but let's go with 20 to be on the safe side :) . I think it would be
most efficient
if Julie or you appropriately change the one line of code in DTGEX2:
THRESH = MAX( TEN*EPS*DNORM, SMLNUM )
All versions (S/D/C/Z) have an analogous line of code with the same
constant TEN that I would change.
Sorry, I've lost track of the Mathworks bug report on dlarfp. Can you
remind me?
Thanks,
Jim
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
author: Vasile Sima
committer: Julien Langou
Corrected LAPACK routines dlagv2 and slagv2 based on Vasile Sima (National
Institute for Research & Development in Informatics, Bucharest, Romania)'s
email to lapack@cs.utk.edu on Monday 25 January 2010.
> Specifically, the variable WI, which is used in the line 268 (close to the
> end), is not initialized (with ZERO) in the cases "A can be deflated" and "B
> is singular" (i.e., the code segments in the lines 138-144, 148-156, and
> 158-167). The corrected version is included in the attached archive.
not sure whether it is needed or not. What I am pretty sure of, is that the
code is correct with, the previous code without may be correct as well ...
Anyway, I like it better like this.
This is
" ( 1 - CONJG( TAU ) ) * ( ALPHA ) = ABS( ALPHA ) "
that needs to be true so, indeed, the previous code was correct and r709 is a
mistake. (r710 is good.) So this commit rollbacks r709 and modifies a little
r710.
modifications. I believe that in the complex case, when NORMX = ZERO but ALPHI
is not ZERO (i.e. ALPHA has a complex imaginary part), then TAU needs to be
such that:
" ( 1 - TAU ) * ( ALPHA ) = ABS( ALPHA ) "
Since we have
ALPHR = REAL( ALPHA )
ALPHI = AIMAG( ALPHA )
XNORM = DLAPY2( ALPHR, ALPHI )
The way to do this is to set TAU with
TAU = CMPLX( ONE - ALPHR / XNORM, ALPHI / XNORM )
as opposed to
TAU = CMPLX( ONE - ALPHR / XNORM, -ALPHI / XNORM )
(Note: XNORM is used as temporary variable here)
Email sent on Thu, 10 Dec 2009 16:53:57 to lapack@cs.utk.edu.
I think we have a bug in dstemr.f for the case when N is 2. The following
block:
392: IF (CS.NE.ZERO) THEN
393: ISUPPZ(2*M-1) = 1
394: ISUPPZ(2*M-1) = 2
395: ELSE
396: ISUPPZ(2*M-1) = 1
397: ISUPPZ(2*M-1) = 1
398: END IF
should really be (note lines 394, 397):
392: IF (CS.NE.ZERO) THEN
393: ISUPPZ(2*M-1) = 1
394: ISUPPZ(2*M) = 2
395: ELSE
396: ISUPPZ(2*M-1) = 1
397: ISUPPZ(2*M) = 1
398: END IF
similarly the block:
415: IF (SN.NE.ZERO) THEN
416: IF (CS.NE.ZERO) THEN
417: ISUPPZ(2*M-1) = 1
418: ISUPPZ(2*M-1) = 2
419: ELSE
420: ISUPPZ(2*M-1) = 1
421: ISUPPZ(2*M-1) = 1
422: END IF
423: ELSE
should really be (note lines 418, 421):
415: IF (SN.NE.ZERO) THEN
416: IF (CS.NE.ZERO) THEN
417: ISUPPZ(2*M-1) = 1
418: ISUPPZ(2*M) = 2
419: ELSE
420: ISUPPZ(2*M-1) = 1
421: ISUPPZ(2*M) = 1
422: END IF
423: ELSE
Email sent on Fri, 11 Dec 2009 14:51:07 to lapack@cs.utk.edu.
Subject: [Lapack] bug in dsyevr.f when N = 1
when dsyevr is called with N=1, then it returns without setting up ISUPPZ values.
331: IF( N.EQ.1 ) THEN
...
342: IF( WANTZ )
343: $ Z( 1, 1 ) = ONE
344: RETURN
345: END IF
It should rather do
IF( WANTZ )
Z( 1, 1 ) = ONE
ISUPPZ(1) = 1
ISUPPZ(2) = 1
END IF
julie