[Rcpp-devel] R & RcppArmadillo decomposition disagreement

[Simon Zehnder]

Hi Colin,

I also found an article referring to a blog of Dirk: http://techyoubaji.blogspot.de/2012/12/r-uses-different-blas-and-lapack.html

Maybe it is interesting for you. 


Best

Simon
On May 31, 2013, at 9:55 PM, Simon Zehnder <szehnder at uni-bonn.de> wrote:

> Isn't this actually an option when installing R (http://www.cran.r-project.org/doc/manuals/R-admin.html)? If it hasn't been explicitly stated in the configure stage of R via --with-lapack, R uses its internal routines.  
> 
> Best
> 
> Simon
> 
> On May 31, 2013, at 9:31 PM, Colin Rundel <rundel at gmail.com> wrote:
> 
>>> For certain operations R does _not_ go to lapack but uses its own. I can
>>> never remember if chol() was one of them -- but this suggests it.  As I
>>> mentioned in my earlier email you probably really have to follow the chol()
>>> call all the way down (in the sources).
>> 
>> I've followed both calls to the best of my ability for both R and armadillo and I'm fairly confident that both ultimately result in a call to lapack's dpotrf.
>> 
>> To simplify things as much as possible I've remove all blas and lapack packages except for:
>> 	libblas3
>> 	libblas-dev
>> 	liblapack3
>> 	liblapack-dev
>>  
>> Looking at the shared library dependencies of the binary created by sourceCpp I get:
>> 
>> > system("ldd /tmp/RtmpTjd5Oq/sourcecpp_7912704276cb/sourceCpp_51716.so")
>>         linux-vdso.so.1 =>  (0x00007fff72cb6000)
>>         liblapack.so => /usr/lib/R/lib/liblapack.so (0x00007fc726530000)
>>         libRcpp.so => /home/rundel/R/library/Rcpp/lib/libRcpp.so (0x00007fc7262b4000)
>>         libR.so => /usr/lib/R/lib/libR.so (0x00007fc725db1000)
>>         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc725aae000)
>>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc725874000)
>>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7254ab000)
>>         libguide.so => /usr/lib/R/lib/libguide.so (0x00007fc725338000)
>>         /lib64/ld-linux-x86-64.so.2 (0x00007fc728374000)
>>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc725033000)
>>         libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fc724d92000)
>>         libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007fc724b50000)
>>         libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc724911000)
>>         liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fc7246ee000)
>>         libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fc7244de000)
>>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc7242c7000)
>>         librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc7240be000)
>>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc723eba000)
>>         libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fc723cab000)
>>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc723a8d000)
>>         libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fc723865000)
>> 
>> I have also created a standalone armadillo implementation (https://gist.github.com/rundel/5687320) which works correctly and results in the following shared library dependencies:
>> 
>> $ ldd chol_test
>> 	linux-vdso.so.1 =>  (0x00007fff6c9fe000)
>> 	liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f8f10088000)
>> 	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8f0fd85000)
>> 	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8f0fb6e000)
>> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8f0f7a6000)
>> 	libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f8f0f506000)
>> 	libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f8f0f1f1000)
>> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8f0eeec000)
>> 	/lib64/ld-linux-x86-64.so.2 (0x00007f8f10da7000)
>> 	libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f8f0ecb7000)
>> 
>> The difference appears to be that the sourceCpp binary is linking to R's lapack (/usr/lib/R/lib/liblapack.so) and not the system lapack (/usr/lib/liblapack.so.3). However, this does not appear to be the case for blas.
>> 
>> -Colin
>> 
>> 
>> 
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> 
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130531/a4331403/attachment.html>