[ITP] R-2.14.1-1

[marco atzeri]

On 2/10/2012 11:39 AM, Corinna Vinschen wrote:
> On Feb 10 10:52, marco atzeri wrote:
>> On 2/10/2012 10:11 AM, Yaakov (Cygwin/X) wrote:
>>> On Fri, 2012-02-10 at 07:30 +0100, marco atzeri wrote:
>>>> On 2/10/2012 4:37 AM, Yaakov (Cygwin/X) wrote:
>>>>> Furthermore, is there a reason you use libRblas/libRlapack instead of
>>>>> the system lapack libraries?
>>>>
>>>> A tough discussion with R developers. They consider the standard Blas
>>>> crippled as non correctly handling NaN.
>>>>
>>>> For what I saw they have the tendency to make their own version of any
>>>> lib that does not fit on their exact expectation, for the same reason
>>>> they do not consider libtool and have a very unusual build.
>>>
>>> Bundling libs is usually a bad idea, and as Debian, Fedora, and Gentoo
>>> all seem to use the system lapack, I'd suggest to do so as well (as done
>>> in Ports).
>>>
>>>
>>> Yaakov
>>>
>>
>> the request was a bit strong
>> https://stat.ethz.ch/pipermail/r-devel/2011-November/062565.html
>>
>> It seems R is assuming math for NaN is a must.
>
> Question:  Are the lapack packages for Debian, Fedora, and Gentoo less
> broken than the Cygwin ones?  If so, why?  Is that just a version
> problem which can be fixed by updating the package or is it due to the
> underlying implementation of some math functions in newlib?
>
>
> Corinna
>

Our blas/lapack is a clean netlib reference implementation,
I have not checked in detail but I expect Debian, Fedora,
and Gentoo are the same.

R expect blas to handle corner NaN case, that are not covered by netlib
(I found nothing on the old netlib blas specification about NaN)
as there are some short path handling multiplication by zero.
I don't know if other implementations handle this case better
or they do not care.

In theory "NaN * 0 = NaN", but if you ignore NaN/Inf existence
you can decide that "anything * 0 = 0" to speed-up the matrix math
and save substantial time on matrix sparse multiplications.

I politely suggested that if the reference is wrong, it should
be patched upstream but I guess there is some "can of worms"
somewhere in the past of the R development community about this issue.

Regards
Marco