On 11/16/2011 11:04 PM, peter dalgaard wrote:
On Nov 16, 2011, at 22:08 , marco atzeri wrote:
On 11/16/2011 9:32 PM, Prof Brian Ripley wrote:
The failures are *not* minor. Please don't distribute an R linked to a
broken BLAS library. Those tests are not for fun: they came from real
errors on real problems.
Dear Brian,
I am reasonable sure that the cygwin blas library are fine, have
you any evidence that they are broken ?
The R test log just reports an issue handling NA that could be
related to cygwin difference to others platform.
I already noted similar difference on cygwin octave package.
Well, on other platforms we have
tcrossprod(x,y)
[,1] [,2] [,3]
[1,] NA NA NA
[2,] 2 1 0
x %*% t(y)
[,1] [,2] [,3]
[1,] NA NA NA
[2,] 2 1 0
so the Cygwin tcrossprod is implicitly letting 0*NA==0 (in the DGEMM BLAS
routine).
This is not what should happen according to the standards, and there are people
whose code relies on standards compliance (and that's why the test is there).
It's also plain wrong, because in extended arithmetic, the missing value could
be Inf, and 0*Inf == NaN, so assuming that 0*anything==0 doesn't work.
-pd
I presume it is a netlib DGEMM issue and not a specific cygwin port issue.
There is an optimization on the reference implementation:
http://www.netlib.org/lapack/explore-html/d7/d2b/dgemm_8f_source.html
00314 IF (B(L,J).NE.ZERO) THEN
that fool any 0*NaN or 0*Inf case
I noticed it was highlighted on octave mailing list long time ago:
http://octave.1599824.n4.nabble.com/NaN-problem-td1662846.html
Time to rise the bug with netlib guys ?
Regards
Marco
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
