NaN and linear algebra

On 23/03/2005, at 12:55 AM, Simon Urbanek wrote:

You may prefer the error, but it is not in the sprit of robust  
arithmetic. ie

d<-matrix(NaN,3,3)
f<-solve(d)

Error in solve.default(d) : Lapack routine dgesv: system is exactly  
singular

f

Error: Object "f" not found

For the record: this is the behavior on all platforms I tested (Mac,  
Linux, IRIX) - the only platform with a different result is  
reportedly Windows. So what I was saying is that this is not  
"IEEE-754 non-compliance of MacOS X" as you put it.

Clearly det(d) returning 0 is wrong.  As a result based on a  
computation including a NaN, it should return NaN.

That's exactly what I was pointing out, and, yes, this is a bug in  
vecLib.

@Martin: I guess the most simple test for this would be probably
is.nan(det(matrix(NaN,2,2)))

Many functions in R will actually bark at NaN inputs (e.g. qr,  
eigen, ...) - maybe you're saying that we should check for NaNs in  
solve before proceeding and raising an error?

However, this problem is in the Apple library not R.

Since you're referencing the "solve" problem here, again, it's not.

As I was explaining the the previous e-mail, there are at least two  
completely separate issues - handling of NaNs in solve and  
determinant of NaN matrices. The latter is a bug in vecLib, the first  
one is not an OS X specific problem. Many R functions will object to  
taking NaN inputs such as qr.solve which was the previous  
implementation of solve. At any rate this is error handling in R and  
not Lapack. The "example" on the top doesn't make any sense because  
when you type "f" you know that it doesn't exist and both are R  
errors. If you used that in a script you have both choices: abort and  
that point or continue with whatever fallback you choose.

Cheers,
Simon