similar to: Switching BLAS/LAPACK without leaving your R session

Hi, for diagnostic purposes, I would like to get information about the BLAS / LAPACK linked against R from within an R-session. An obvious application could be safety-checks for packages like Matrix and quantreg at load / attach - time. Also you could be more precise on the "framework" in which R is running for comparable benchmark timings on different systems. Perhaps this

I'd like to build R using my optimized blas and lapack libraries. It seems know matter what I do, the configure script uses the blas supplied with the source. My blas and lapack libraries are in /usr/local/atlas/lib. How can I get configure to use these? [[alternative HTML version deleted]]

R-devel has the --with-lapack flag for configure. If you build R with --with-blas="-framework vecLib" --with-lapack="--framework vecLib" then the build goes through, using the native optimized BLAS and Lapack in /System/Library/Frameworks/vecLib.framework. Also, it works, in the sense that it does eigenvalue problems correctly. I don't have any timings yet, because I

A couple of years ago I noted that using the configure switch --enable-R-shlib when buildig R made configure ignore any specified external LAPACK library (I cannot recall if also the BLAS specification was ignored) and use the internal one insted. I asked why, and was told it was intentional. Now, with R 2.15.1, I see that it at least appears that this is no longer the case. I've run

Hi, I am working on a UNIX machine and I am interfacing R and C with the .C function. I am trying to call LAPACK and BLAS routines, but am running into a problem where, while I am able to run the BLAS routines, I cannot run the LAPACK routines. I compile my .c file (at end of email) in the following way: [mhitczen at jlogin2 ~/Cstuff]$ R CMD SHLIB testmore.c gcc -std=gnu99

A couple of years ago (in 2008, using R 2.7.x, I believe) I noted that using the configure switch --enable-R-shlib when buildig R made configure ignore any specified external LAPACK library and use the internal one insted. I asked why, and was told it was intentional. Now, with R 2.15.1, I see that it at least appears that this is no longer the case. I've run configure like this:

Executive summary: I believe revision 86265 makes it more difficult to build R with OpenBLAS on Windows as now the entire LAPACK needs to be built to obtain zspmv. Is there anything that can be done to allow the former behavior to be used, something in Mkrules.local perhaps? Detailed Explanation: I have been building R with OpenBLAS for Windows 64 for over a decade by patching

Dear Madlene, while this list serves as a forum for discussions about R backports present on CRAN, this would be something preferably filed in the Debian bug tracking system bts.debian.org - could you file a bug there? But please don't ask me on which package - maybe Dirk has a good answer to that one... Cheers, Johannes P.S.: https://www.debian.org/Bugs/Reporting Am Dienstag, 16.

Dear developeRs, I'm trying to build R (2.7.1, on an x86_64 running Linux, but I believe I have observed this on x86 and with earlier versions of R as well) using external BLAS and LAPACK libraries _and_ generating libR.so, libRblas.so and libRlapack.so. Without --enable-BLAS-shlib, configure is able to find and use the external LAPACK library: ./configure \

Hi, I don't know if I'm sending this to the right place but I've looked throught tens and tens of topics on http://tolstoy.newcastle.edu.au/ and finally found that email address where I can maybe find some help. Well my main goal is to get to use the lapack library within my R package (which can be done using calls from C). But in order to do this I have to create a file src/Makevars

Hi, I don't know if I'm sending this to the right place but I've looked throught tens and tens of topics on http://tolstoy.newcastle.edu.au/ and finally found that email address where I can maybe find some help. Well my main goal is to get to use the lapack library within my R package (which can be done using calls from C). But in order to do this I have to create a file src/Makevars

Dear all Some computations gave a matrix. The single value decomposition of it worked fine previously, after an system upgrade I get the following error: ----- > La.svd(x,256,256) Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DLASCL' gave error code -4 ----- Erroneous Matrix: ftp://usys-ftp.ethz.ch/ITES/STEP/nussbaum/R/matrix-lapack-error4.RData /.csv Operating System: Debian 8

Hello, This simple SVD calculation (commands are copied immediately below) crashes on my Ubuntu machine (R 2.13.0). However it worked fine with R.12 and Ubuntu 10.04, and it also works fine on my Windows 7 machine with R 2.13, so I suspect there's a problem with (my?) Ubuntu and / or R. I'm using the R distribution that is accessible with Ubuntu's repositories manager, I am not

On 16 December 2014 at 14:45, Johannes Ranke wrote: | this list serves as a forum for discussions about R backports present on CRAN, The mandate, as I recall, is a little broader: "usage of R on Debian-based systems" As such, I found the post perfectly adequate. We redirect from r-help and other lists to here because it is the one focus point for all things related to Debian / Ubuntu

On 30 December 2023 at 23:49, Ramon Diaz-Uriarte wrote: | All is good. (Just for the sake of curiosity, and if you have the time: why did you find those incantations suspicious?) Memory is fuzzy and no ECC in my wetware :) but as I seem to recall it had to do with my fears over filenames not being standardized enough / this interfering with the update-alternatives mechanism. May well have been

OS X 10.2 and higher comes standard with highly optimized versions of BLAS and Lapack in /Systems/Library/Frameworks/vecLib.framework. It seems that even for double precision they do much better. See http://sthmac.magnet.fsu.edu/benchmarks/ I am not sure how these numbers would look on G3 Macs, but obviously for double precision there is not much reliance on Altivec. So I tried to configure

Greetings - For a host of reasons I chose (was forced) to upgrade my multi-Opteron box from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had installed from 4.0.0 to 4.1.0. While I get no errors (that I can find) in the config -> make -> make install sequence, I'm pretty sure (based on some benchmarks) that I'm not getting BLAS and/or Lapack to compile in. So,

Hello. I am a Linux neophyte and know almost nothing ?about compiling, so I would appreciate any help and advice y'all would care to offer. I am trying to compile the 64 bit version of R using a tuned ATLAS and LAPACK (ATLAS 3.9.24). I am running Ubunto 10.04 LTS (through wubi, FWIW). The ATLAS and LAPACK files (atlas.so, f77blas.so, lapack.so, and cblas.so) are sitting in the folder

Dear All, I am building R from source[1], following what is done in "rules" for building Debian's R. But the R I generate, in contrast to the standard Debian's R, will not change the BLAS and LAPACK libraries it uses when I change them via "update-alternatives". I have no idea what I am doing wrong (but, somehow, I've been quite capable of making the same

Thanks I?aki, that is exactly what i was looking for, esp the last option which I have now configured as an alias for easy remembering. I can answer the question re USE_LOCKING=1. I think that using both those options is required to get thread-safety even if openblas was compiled for single thread use. I don't know to what extent Simon has engaged with upstream on this etc. All I know is