[Rd] cygwin R-2.14.0 build fail

[marco atzeri]

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