lapacke_?laset has limitations

Post here if you want to report a bug to the LAPACK team

lapacke_?laset has limitations

Postby Victor_K » Thu Jul 09, 2015 12:09 am

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?
Victor_K
 
Posts: 5
Joined: Sat Nov 27, 2010 9:48 am

Re: lapacke_?laset has limitations

Postby admin » Thu Jul 09, 2015 10:56 pm

Thank you Victor,
This bug has been listed as bug 128 in http://www.netlib.org/lapack/Errata/index2.html
Julie
admin
Site Admin
 
Posts: 608
Joined: Wed Dec 08, 2004 7:07 pm

Re: lapacke_?laset has limitations

Postby Julien Langou » Wed Aug 26, 2015 12:59 am

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.
Julien Langou
 
Posts: 821
Joined: Thu Dec 09, 2004 12:32 pm
Location: Denver, CO, USA


Return to Bug report

Who is online

Users browsing this forum: No registered users and 1 guest