I am sorry that I wasn't clear. All that I meant was that *this* problem can result in different behaviour in "ordinary" statistical applications. For example, if the objective function in a call to optim() involves calling one of these linear algebra routines, the result may be NaN (on systems other than Mac OS X) --- which optim will typically handle sensibly --- or something else (an error, or perhaps some consequence of getting 0 for the determinant) under Mac OS X .
Probably this was obvious to you. Apologies if I misled you into thinking that there was some other problem I knew about.
Best regards, DavidAt 11:57 AM +0000 3/16/05, David Firth wrote:I don't know whether this is a bug, or a problem with the way I built R 2.0.1 (under Mac OS 10.3 on a G5), or something else. Can anyone else confirm (or otherwise) that this happens in their R 2.0.1 on Mac OS X?
d<-matrix(NaN,3,3) d[,1] [,2] [,3] [1,] NaN NaN NaN [2,] NaN NaN NaN [3,] NaN NaN NaNsolve(d)Error in solve.default(d) : Lapack routine dgesv: system is exactly singularchol(d)Error in chol(d) : the leading minor of order 1 is not positive definitedet(d)[1] 0
Doing the same thing on a Windows setup gave a different (and more useful, I think) result
As I see it, the MacOS X behaviour is not IEEE-754 compliant.
I had a quick look at the IEEE web site and it seems quite clear that NaNs should not cause errors, but propagate through calculations to be tested at some appropriate (not too frequent) point.
It seems to me the most useful response is to file a bug on Apple's bug reporter complete with simple test case etc. It might also help to bitch about it on Apple's scitech or hpc mail lists, which get monitored by Apple people.
It certainly is not up to R developers to fix it.
Bill Northcott
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
