From: Zlatko Drmac
Date: Wednesday, April 15, 2026 at 9:47 AM

First a summary:

X and Y are data that define implicitly a matrix A such that A*X \approx Y. So, in principle the caller can input any X and Y.   

However, if scaling options are active, the subroutine uses the opportunity to check for some inconsistencies - like all X is zero, or some are NaNs. Having all X zero indeed suggests something is wrong with the data. This is again checked after the SVD of X - if largest singular value is zero, error code -8 is returned.

If scaling of Y is selected, detected NaNs will trigger an error message. If all Y are zero, this also suggests something is wrong with the data, although it may implicitly define a zero matrix - this again is something that the caller probably did not want.

So, this is something I call "a political decision" - the roles of X and Y are not symmetric in this case but one can simply define/declare that zero input (X or Y) will be reported as error. This is what is in the proposed correction. Perhaps it should be done. Otherwise, DGEEV will get a zero matrix on input. In DGEEV you have a quick return if N=0. On the other hand, to check for scaling DGEEV computes ANRM and scales if needed but it does not use the opportunity for quick return if ANRM=0.

So, I would say it is OK to return an error code if Y=0. The only "con" is that then the subroutine behaves differently if scaling of Y is not requested and Y=0. 

(For X=0, even without scaling, after the SVD X=0 will be detected and reported error.)

So, in the end, it is a "political decision" 😀

From: Zlatko Drmac
Date: Thursday, April 16, 2026 at 8:51 AM

It is indeed important to discuss all aspects of such "singularities". Well designed behaviour for singular cases may save the day in mission critical applications.  

If Y = 0 then the matrix whose eigenpairs were to be identified is zero matrix (based on the supplied data) so in principle the question is what an eigenvalue subroutine should return if zero matrix is given as input? If this is DGEEV then it should return eigenvalues and eigenvectors (which ones) of the zero matrix. In the DMD case we can say zero matrix is something unheard of and  return error code.  Making the change as suggested is OK, but also some another flag could be raised. E.g., note that DGEDMD uses positive values of INFO to return some diagnostics/warnings. So it would be also wise to update INFO to make sure the caller is well informed. 

Framing this as a "political decision" makes me wonder if the change would break existing user code. Returning early if no useful work can be done is one thing, but erroring out in what I assume to be a benign case (continuing would not cause an exception or loop(?) ) would only put unexpected burden on users to check their inputs (making the added code in LAPACK redundant) or to catch the error.
INFO is already set to 1 when a quick return is made on void input, i.e. M or N zero, perhaps this could be used for the Y=0 case as well ? With the datum being informational, it also wouldn't matter as much that the check is done in one code path only.

Thanks, I agree that treating the all-zero Y case as INFO = -10 was too strong.

I have updated the change accordingly. The JOBS='Y' all-zero-Y case is now reported as INFO = 5, documented as a positive diagnostic, and no longer routed through XERBLA. The routine returns early with K = 0 in this case.

The motivation is to keep the explicit detection of the degenerate JOBS='Y' scaling case, while avoiding reclassifying it as an illegal 10th argument. In other words, this is now treated as a degenerate-input diagnostic rather than an argument error.

I also chose not to reuse INFO = 1, since that already denotes the void-input quick return (M = 0 or N = 0), and it seemed better to let callers distinguish empty input from the all-zero-Y case.

Finally, I updated the corresponding *GEDMDQ wrappers so that INFO = 5 is propagated as a terminal diagnostic from the underlying *GEDMD call.