Re: [Rd] R Lapack – why a subset?

Peter, Is there not already a significant maintenance burden from cherry-picking routines? From my own experience (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16482 ) this is a painful process. And while users may not call the

Re: [Rd] Inconsistent rank in qr()

A simpler fix: return rank=NA when Lapack is used. Keith > On Jan 23, 2018, at 5:36 AM, Serguei Sokol wrote: > > Le 23/01/2018 à 08:47, Martin Maechler a écrit : >>>>>>> Serguei Sokol >>>>>>> on Mon, 22 Jan 2018 17:57:47 +0100 writes: &

Re: [Rd] Inconsistent rank in qr()

in two places (around lines 657 and 1175). Keith > On Jan 22, 2018, at 11:57 AM, Serguei Sokol wrote: > > Le 22/01/2018 à 17:40, Keith O'Hara a écrit : >> This behavior is noted in the qr documentation, no? >> >> rank - the rank of x as computed by the decomposi

Re: [Rd] Inconsistent rank in qr()

This behavior is noted in the qr documentation, no? rank - the rank of x as computed by the decomposition(*): always full rank in the LAPACK case. > On Jan 22, 2018, at 11:21 AM, Serguei Sokol wrote: > > Hi, > > I have noticed different rank values calculated by qr() depending on > LAPACK p

Re: [Rd] OpenBLAS in everyday R?

a to install R and > OpenBLAS. So I guess we should be barking up the conda tree instead? > > By the way, I also noticed on my home machine (Ubuntu), > /usr/lib/libopenblas.so.0 is also not linked against those, for what that's > worth. > > Regards, > Ben >

Re: [Rd] OpenBLAS in everyday R?

ote: > > On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara wrote: >> >> Check if libopenblas is linked against libomp or libgomp. >> >> I’d be curious to see any errors that arise when an OpenMP version of >> OpenBLAS is linked with R. >> >> Ke

Re: [Rd] OpenBLAS in everyday R?

ggs, so to speak. > > > On 01/09/2018 06:41 PM, Keith O'Hara wrote: >> Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ? >> >> Keith >> >>> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner wrote: >>> >>> Ple

Re: [Rd] OpenBLAS in everyday R?

Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ? Keith > On Jan 9, 2018, at 6:03 PM, Benjamin Tyner wrote: > > Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely > with multi-threaded OpenMP? (for example, don't race conditions sometimes > c

Re: [Rd] OpenBLAS in everyday R?

On point 1): The standard approach seems to favor the reference BLAS for reasons other than speed. For example, vecLib, Apple's multi-threaded BLAS library, is not the default choice for macOS binaries due to concerns about 'precision'. See: https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.htm

Re: [Rd] Latest R-devel build failing on OS X

svn checkout https://svn.r-project.org/R/trunk/ > On May 24, 2016, at 12:45 PM, frede...@ofb.net wrote: > > I agree with Martin's summary of the situation, and with the updated > NEWS entry. > > I'm not familiar with Subversion, can you tell me the command to use? > > (I tried "svn co https://

Re: [Rd] Latest R-devel build failing on OS X

On my machine (iMac w/ El Capitan (10.11.4)), svn rev. 70662 builds without any errors (and the warning I mentioned before is now gone too). K > On May 24, 2016, at 6:55 AM, Martin Maechler > wrote: > > > Can you (Frederick, Peter, Keith, but ideally others, too) > confirm that you don't see

Re: [Rd] Latest R-devel build failing on OS X

dline_state", referenced from: >> _popReadline in sys-std.o >> "_rl_resize_terminal", referenced from: >> _Rstd_ReadConsole in sys-std.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (us

[Rd] Latest R-devel build failing on OS X

Dear R-devel, The latest version of R-devel (05-17) is throwing an error for me when building on OS X (v 10.11.4): making Rembedded.d from Rembedded.c making dynload.d from dynload.c making system.d from system.c making sys-unix.d from sys-unix.c making sys-std.d from sys-std.c making X11.d from