[Rd] cygwin R-2.14.0 build fail

[Uwe Ligges]

On 17.11.2011 00:34, marco atzeri wrote:
> 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 ?

Everybody in this discussion invested too much time on it already. If 
you want to provide cygwin support for others, go ahead and tackle the 
problems, but don't distribute incorrectly working versions of R.

Best,
Uwe Ligges



> Regards
> Marco
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel