similar to: Lapack or Blas crashing R when using "large" matrices (Ubuntu 11.04)

Sorry for re-posting, but the original one ended up inside a previous and unrelated thread. -- Matias ----- Hello, This simple SVD calculation (commands are copied immediately below) crashes on my Ubuntu machine (R 2.13.0). However it works fine on my Windows 7 machine, so I suspect there's a problem with (my?) Ubuntu and / or R. Can anybody else reproduce it (with Ubuntu 11.04)? Thanks

Dear All, I have been trying to compile a package for windows that we have written. Since R version 3.0.0 the package doesn't compile any more. (On Linux the package compiles without errors). The error specifically says: gcc -m32 -I"C:/PROGRA~1/R/R-30~1.0/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O3 -Wall -std=gnu99 -mtune=core2 -c

Hello, I'm using the eclat function of the arules package (1.0-6) for the identification of frequent itemsets. I need the tidLists, but if I set in the function tidLists=TRUE R crashes (Windows XP Professional SP3, 32 bit, R version 2.12.1 (2010-12-16), reproducible on two different computers) with two different error messages or non at all. Minimum examples are: library(arules)

Hi, I'm relatively new to R on Ubuntu (moving from Windows), and I'm trying to get GotoBLAS2 working. I installed (from a CRAN mirror) the pre-built binaries of R (which, as far as I know, is compiled as a shared library) on Ubuntu 10.10 using apt-get install r-base r-base-dev I successfully built GotoBLAS2 from source, copied the library to /usr/lib and created s symbolic link from

Dirk Eddelbuettel <edd <at> debian.org> writes: > One last follow-up. Debian's Atlas maintainer has started to work in the > OpenGoto packaging. There will be proper Goto packages now that the license > is better, but it may take a while. It took years to get Atlas packaged > 'right' so don;t expect anything too soon. The gotoblas2-helper package is >

I've attempted to use the optimized GotoBLAS2 library with a freshly compiled R-2.11.1 patched on 64-bit Ubuntu 10.4. (See details below). When I run this version of R, the timings are not different than the original install, and only one core is used in test computations. Can someone point out my error? Thanks. --Dale Details ... I'm running the 64-bit version of Ubuntu 10.04 on my 2

Hi all, I have a problem with cpu affinity in my R-2.11.1 installation compiled against ATLAS running on a Linux (Ubuntu 10.04) cluster under GridEngine. I wish to use Grid Engine's core binding feature to bind user processes into the number of cores they request on the cluster, thus preventing badly behaved multi-threaded libraries from consuming more cores than requested. An example of

Hi, I put below Rblas.dll(GotoBLAS2 for Win64). http://prs.ism.ac.jp/~nakama/SurviveGotoBLAS2/binary/windows/x64/Rblas.dll It's a tryal phase. -- EI-JI Nakama? <nakama (a) ki.rim.or.jp> "\u4e2d\u9593\u6804\u6cbb"? <nakama (a) ki.rim.or.jp>

Can one of you give me an R program that displays the benefits an accelerated BLAS in R? Here's why I ask, in case you wonder: In a linux cluster, I've hit some bumps in the road. The worst one by far was that I installed R, then GotoBLAS2 with default settings, and after that, jobs using Rmpi were *really* *really* slow. I mean horrible. If a job took 15 minutes when run by itself,

Professor Ripley commented on LAPACK error codes: https://stat.ethz.ch/pipermail/r-help/2007-March/127702.html and says "Internal LAPACK errors are usually problems with arithmetic accuracy, and as such are compiler- and CPU-specific." Is there a listing for the error codes from Lapack routine 'dsyevr'? Especially I am interested about the meaning and handling of error codes 1

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]]

Hi all, We are excited to announce that this new feature is coming to Fedora 33, which is in beta state. See [1] or [2] for more information on how to test it. [1] https://cran.r-project.org/bin/linux/fedora/ [2] https://www.enchufa2.es/archives/switch-blas-lapack-without-leaving-your-r-session.html Regards, -- I?aki ?car

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.

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

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

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

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:

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

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