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
