lapacke_?laset has limitations

[Victor_K]

The code of lapacke_dlaset.c assumed NaN checking as follows
...
#ifndef LAPACK_DISABLE_NAN_CHECK
/* Optionally check input matrices for NaNs */
if( LAPACKE_dge_nancheck( matrix_layout, m, n, a, lda ) ) {
return -7;
}
if( LAPACKE_d_nancheck( 1, &alpha, 1 ) ) {
return -5;
}
if( LAPACKE_d_nancheck( 1, &beta, 1 ) ) {
return -6;
}
#endif
...

Matrix pointed by a is assumed to be initialized by this functions and should not be checked for NaNs. The array may contain NaNs and in such a case the function will return -7 without initialization.

I even doubt that parameters alpha and beta should be checked for NaN. From one point of view, it is OK if the matrix is assumed to be processed by some LAPACK function but from other point of view it is restriction of functionality. A user may want to initialize the matrix with NaNs - why would not we allow to do so?

[admin]

Thank you Victor,
This bug has been listed as bug 128 in http://www.netlib.org/lapack/Errata/index2.html
Julie

[Julien Langou]

Hi Victor,

We just committed r1580. Here is how the log reads.

When LAPACK_NAN_CHECK is enabled, in input of xLASET, we now allow the matrix A to contain NaNs.

Since the goal of xLASET is to set values in A, we consider it OK if A contains NaN in input.

In other words, the rationale is that we do not consider A has an input/output. We consider A as an output only.

Note: We allow neither alpha nor beta to be a NaN.

(So we do check for NaN in alpha and in beta and return error if NaN.)

So this commit
(1) removes the NaN check on matrix A in LAPACKE wrappers: lapacke_?laset.c
(2) declares that A is OUTPUT in LAPACK subroutines: ?laset.f

I think, when LAPACK_NAN_CHECK is enabled, the rationale is to check all INPUT for NaNs. So, since alpha and beta are input, we need to check them for NaNs and return an error if we find NaNs. This follows the rationale. I understand your point. Returning an error reduces the functionality of xLASET. We cannot use xLASET when LAPACK_NAN_CHECK is enabled to initialize a matrix with NaN. But this is what NaN check is about. If a user wants NaN propagation / NaN initialization within LAPACK, he/she should not enable LAPACK_NAN_CHECK. I think it is important to stick to a rationale on this otherwise this can quickly become a zoo. We cannot allow exceptions.

So this is my take on it. I might be shortsighted. If there are more opinions agreeing with Victor, more arguments, I am happy to change my mind.

Julien.