This relates to the unpredictable behavior of the intrinsic MAX function in FORTRAN when one has a NaN as argument. We can speak about this. Of course, we can preprocess the data to check for NaNs. (We have a DISNAN function so this should not be too hard.)I think we could also use an INTRINSIC for this.

( I just edited my post. ) I am not too much in favor of having the output of the matrix norm depends on a compilation flag.I.e. having the behavior of the library depending on a compilation flag. I am not sure this is what you were proposing though.

However if it depends on an input argument, why not. We can offer other behaviors through other flags though. This can be done at the Fortran level actually. There are plenty of characters different from M, F, I, O, 1, m, f, i, o. ( ?? )

If we need to decide for one behavior, I am in favor of having NaN returned for the norm (any norm) when the matrix has some Nans.

...If we need to decide for one behavior, I am in favor of having NaN returned for the norm (any norm) when the matrix has some Nans.

Cheers, Julien.

Hi, Julien,

At the moment it looks fine to have one behavior and I strongly support your suggestion.

Anyway a variant returning max(abs(A(i,j))) omitting NaNs could be added in the future if needed.

With reference to std::max(NaN,1.0) = NaNstd::max(1.0,NaN) = 1.0: yes I met similar issue. Result in this example depends on an implementation of MAX routine; logical operations involving NaN always return false.

I have modfied all of the 54 norm functions in LAPACK to consistently return a NaN when the input matrix contains a NaN. The new versions of the norm functions can be obtained from the trunk of the LAPACK svn repository:

On a related note: Jack Poulson found that ZLARTG has an infinite loop related to NaN .EQ. 0. It's the line below "ELSE IF( SCALE.LE.SAFMN2 )" between 10 and 20. When G is NaN, then the loop goes forever.