On Mar 22, 2005, at 6:19 PM, Bill Northcott wrote:
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
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
