From ripley at stats.ox.ac.uk  Thu Sep 22 11:27:11 2005
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Thu, 22 Sep 2005 10:27:11 +0100 (BST)
Subject: [Rd] looks in liblapack.a not liblapack.so
In-Reply-To: <x2mzm5lbtx.fsf@turmalin.kubism.ku.dk>
References: <mailman.9.1126951201.11292.r-devel@r-project.org>
	<20050917221902.GA10806@stat.umn.edu> <1127119440.3624.5.camel@seurat>
	<x23bo15c13.fsf@turmalin.kubism.ku.dk>
	<1127144443.18426.14.camel@seurat>
	<dgpari$a96$1@sea.gmane.org> <x2mzm5lbtx.fsf@turmalin.kubism.ku.dk>
Message-ID: <Pine.LNX.4.61.0509221013230.14847@gannet.stats>

Which confirms the wisdom of our advice not to use --with-lapack unless 
you have to (a few systems do).  (Quote from the R-admin manual

 	this is definitely *not* recommended

. Perhaps this needs to say `use at your own risk and do not report 
problems with it'!)

There are far too many rogue LAPACK builds out there in distros.

BTW, I don't understand how a Linux distro can supply ATLAS tuned to my 
CPU/FPU.  Dr Goto has had about ten versions of his optimized BLAS 
covering just a small subset of i686 CPUs.  So although a distro's ATLAS 
may be better than a generic BLAS, it seems that it is likely to be 
suboptimal, and perhaps disastrous (I've seen that with mobile Pentium 
chips using ATLAS tuned on desktop machines).  So the recommendation must 
remain to tune ATLAS on your specific hardware.


On Thu, 22 Sep 2005, Peter Dalgaard wrote:

> Jos? Matos <jamatos at fc.up.pt> writes:
>
>> Martyn Plummer wrote:
>>
>>> Fedora have just split off a separate lapack-devel package containing
>>> the static library and the symlink liblapack.so.  (Mandrake/Mandriva has
>>> been doing this for some time. I don't know about SuSE).  The up2date
>>> service will recognize that it needs to update lapack, but I guess that
>>> it won't install lapack-devel, as it doesn't know you need it.
>>
>>   You are right.
>>
>>> It might have been better to do this in the next release, rather than as
>>> an update to FC4, but there you go. Better install lapack-devel
>>> manually.
>>
>>   lapack belongs to Extras and not to Core. Extras is a rolling release.
>>
>>   The change was necessary to allow atlas to compile and interact with
>> lapack.
>>
>>   atlas is on the queue to Fedora Extras, it is in the review phase now.
>
> Hmm. Doesn't look like it is actually working, though. Install
> lapack-devel, configure --with-lapack, and make check dies with
>
> running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
> make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples'
> make[3]: *** [test-Examples-Base] Error 2
> ....
> [pd at titmouse BUILD]$ tail tests/Examples/base-Ex.Rout.fail
>> kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
> [1] 8.351867e+16
>>
>> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
>> sv9 <- svd(h9 <- hilbert(9))$ d
>> kappa(h9)# pretty high!
> [1] 728289254735
>> kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
> Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGEBRD' gave error code -10
> Execution halted
>
> This happens on both x86_64 and x86 installs of FC4.
>
> I have a strong sense of deja vu regarding this error.
>
> -- 
>   O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
>  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


[Rd] looks in liblapack.a not liblapack.so
Prof Brian Ripley