Page 1 of 1

lapacke_?laset has limitations

PostPosted: Thu Jul 09, 2015 12:09 am
by Victor_K
The code of lapacke_dlaset.c assumed NaN checking as follows
/* 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;

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?

Re: lapacke_?laset has limitations

PostPosted: Thu Jul 09, 2015 10:56 pm
by admin
Thank you Victor,
This bug has been listed as bug 128 in

Re: lapacke_?laset has limitations

PostPosted: Wed Aug 26, 2015 12:59 am
by 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.