LAPACKE_?laswp - correct nancheck is no nancheck ?

[dbakshee]

The row swap functions have an option of checking if the input matrix contains NaN entries. However, the arguments of the function do not tell the row size of the input matrix.

Passing LDA instead of the unknown row size to the NaN checking function is not very good idea. The NaN checking function should not check the memory that is not part of the matrix.

As an option, the laswp function could have guessed the lower boundary on the row size of the matrix by scanning the pivot array first. This option does not look appealing too, because the guess may not give the actual row size of the matrix.

Even if the guess is correct, checking full matrix may be redundant. For instance, the pivot could describe just one interchange of the first and the last row, and the laswp function would have to check for NaNs the whole matrix while swapping just only two rows of it, which does not seem a good thing to do.

As yet another option, the function could do the NaN check only on the rows it interchanges. This would penetrate the NaN check into the computation and break the pattern of ‘first check, then compute’.

Perhaps, removing the NaN checking option from the LAPACKE_?laswp functions is the best option.

What do you think about this?

Thanks
Dmitry

[Julien Langou]

Hi Dmitry,

Passing LDA instead of the unknown row size to the NaN checking function is not very good idea. The NaN checking function should not check the memory that is not part of the matrix.

Indeed . . . !!!! Not a good idea at all!

You are proposing three possible fixes.

(1) guessing the lower boundary on the row size of the matrix by scanning the pivot array first
=> Fun! Yes, that's doable. And a rationale of doing so could be "we do NaN check on the region of A that is impacted by the pivot." Would work with me.

(2) NaN check only on the rows it interchanges. This would penetrate the NaN check into the computation and break the pattern of ‘first check, then compute’.
=> Yes, this would make sense as well. But this would be very intrusive indeed. Something to think about. This would be nice and elegant. But very intrusive. I do not think we are ready for this.

(3) removing the NaN checking option from the LAPACKE_?laswp functions
=> I agree that this might be the best option for now. We could disable the NaN check in LAPACKE_?laswp, have a comment in the code, and wait to see how this NaN check things evolve.

I agree with you. Thanks for the post!

Julien.

[Julien Langou]

Thanks Dmitry. For now, as a temporary fix, I disabled the NaN check in LAPACKE_?laswp. (See rev 1607.) This might become the permanent behavior. We will see. Thanks! Julien.