From marco.atzeri at gmail.com  Thu Nov 17 00:34:01 2011
From: marco.atzeri at gmail.com (marco atzeri)
Date: Thu, 17 Nov 2011 00:34:01 +0100
Subject: [Rd] cygwin R-2.14.0 build fail
In-Reply-To: <5B230290-335A-4825-9C2A-D30E54028A43@gmail.com>
References: <1321107923.21160.YahooMailNeo@web27002.mail.ukl.yahoo.com>
	<4EC3D2BD.8070008@gmail.com>
	<alpine.LFD.2.02.1111162027520.28593@gannet.stats.ox.ac.uk>
	<4EC42656.6010704@gmail.com>
	<5B230290-335A-4825-9C2A-D30E54028A43@gmail.com>
Message-ID: <4EC44869.3040206@gmail.com>

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



[Rd] cygwin R-2.14.0 build fail
marco atzeri