lapackers

[julie langou <julie@cs.utk.edu>]

Hi,

We are planning for a LAPACK bug-fixrelease sometime soon (before june for sure)

Below is the list of the known bugs  (more info available here:  http://www.netlib.org/lapack/Errata/index2.html)

Thanks to Rodney (UCD) we managed to either correct or confirm each bug. 

What is remaining ( except bug0024 and bug0065) are non trivial bugs. I am planning to correct bug0024 and bug0065 will be addressed in the next major release.

Please let me know 

 - whether you are planning to tackle one of those remaining bugs.

 - or if you are ok with the bug-fix release at it is.

Thank you

Julie

bug0065 :: workspace queries not being used

• CONFIRMED

• bug report by Clint Whaley on October 27th, 2010

• DGESVD does not perform a workspace query on worker

• functions such as DGELQF, but rather it hardwires in an assumption as

• to LQF’s workspace requirements. This means that if LQF is changed,

• GESVD breaks. This actually happens in ATLAS, because we provide a

• faster GELQF, which sometimes uses extra workspace. For LAPACK itself,

• it represents extra dependencies that don’t need to be there.

bug0061 :: zgehrd.f is overflowing

• CONFIRMED

• bug report by Victor Liu on Tuesday August 03rd, 2010

• zgehrd.f is overflowing the maximum size in bytes of the largest array that

• can be put on the stack with gfortran (⇒ leads ,e.g., to non-reproducible and uncorrect execution

• of zgeev in multithreaded context

• lapackers involved in the bug fix process: Julie and Julien Langou and Mathieu Faverge

• bug fix by Victor Liu on Wednesday August 04th, 2010

• see forum topic 1930

• two outstanding issues: (1) how do we go to fix this?, (2) more LAPACK subroutines might be concerned.

bug0057 :: Non-eigenvectors from DGEEV, problem in balancing

• CONFIRMED

• bug report sent by Numpy team on April 22nd, 2010

• see forum topic 1818

• see follow-up on lapackers on April 22nd from Jim "bug in DGEHRD" "The balancing is choosing to scale some rows/columns by factors like 1e18, which rather amplifies tiny rounding errors in the (presumably correctly) computed eigenvectors of the balanced matrix, when balancing is undone at the end. The expert driver interface dgeevx would let the user disable balancing, until we figure out whether this is a bug or a feature, I’m not sure which."

bug0056 :: Non-orthogonal eigenvectors returned from DSYEVR

• CONFIRMED

• bug report sent by Scipy team on April 22nd

• see LAPACK Mailing list msg 874

• Confirmed by Rodney on Tue, 17 Feb 2011

• " I can reproduce similar problems that the user encountered with non-orthogonal eigenvectors when only

• a few eigenvalues are requested. This also happens with SSYEVR. If I set ABSTOL to SLAMCH(Safe minimum),

• the problem goes away in SSYEVR, and improves with DSYEVR but does not completely go away."

bug0033 :: failure of zheevd on a specific matrix

• CONFIRMED

• bug report sent by Cezary Sliwa (Instytut Fizyki PAN, Poland) on Thu 2 Jul 2009 to "lapack@cs.utk.edu".

• see Cezary Sliwa’s test code, Cezary Sliwa’s matrix, and Cezary Sliwa’s email.

• Confirmed by Rodney on Tue, 17 Feb 2011

bug0032 :: matrix splitting problem with dstebz and sstebz

• CONFIRMED

• bug report sent by Phil DeMier (IBM) on Mon 29 Jun 2009 to "lapack@cs.utk.edu". "matrix splitting problem with dstebz and sstebz"

• see Phil DeMier’s email and Phil DeMier’s test code

• Confirmed by Rodney on Tue, 17 Feb 2011

bug0028 :: failure of convergence of DHGEQZ for some specific matrix pencils

• CONFIRMED

• reported by Vasile Sima on Thu Jan 22 2009

• see: email from Vasile

• more information at: see lapack known issues

• related to bug0026 below

• Confirmed by Rodney on Tue, 08 Feb 2011

bug0026 :: problem when playing with DGEEV and gfortran optimization flags

• CONFIRMED

• reported by Pauli Virtanen (scipy team) on Sat Dec 06 2008 (email to lapack@cs.utk.edu)

• see: email from Pauli Virtanen see: http://scipy.org/scipy/scipy/ticket/709

• problem appears to be with an underflow producing alpha=beta=zero eigenvalues for some cases in the above test code

• it does not depend on the compiler options in later versions of gfortran (and other compilers), and is also present in SGEEV

• most likely these issues are due to the shift strategy for QZ

• Confirmed by Rodney on Tue, 08 Feb 2011

bug0024 :: the notation A' is confusing for complex matrices. Does A' stand for A transpose of A Hermitian transpose?

• CONFIRMED

• reported by Clint Whaley early July 2009

• LAPACK is not consistent in it use of the notation for transpose and Hermitian transpose.

• The use of LAPACK A' is not consistent with the BLAS useage.

• We note that the Matlab/Scilab/Octave convention is A' stands for "conjugate transpose" and A.' stands for "transpose".

• In the Z routines, LAPACK uses the notation A' 669 times, it means "conjugate transpose" most of the time but it means "transpose" a few times (maybe 10 times max, for BLAS-like routines). The notation A*H, A*T, A*N is used 549 times, The notation AT, AN, A^H 19 times. (This is just for the Z routines.)

• see Julien’s emails

• vote on the lapackers mailing list: A*T (or AT) and A*H (or AH): Clint Whaley, Jim Demmel, Sven Hammarling, Antoine Petitet, Daniel Kressner A' (for A*H) and A.' for (A*T): Julien Langou (I love to be that supported by the lapackers!)

bug0020 :: in xGESDD, workspace query can overflow for large matrices

• CONFIRMED

• reported by Stephan Ripke (Broad Institute, Boston) on Thu May 21 2009

• confirmed by Julien Langou on Thu May 21 2009

• see forum topic 1418