Re: [Rd] R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

works with intel 2011.10, at least: BLAS=--with-blas='-mkl=parallel' LAPACK=--with-lapack ## To make the linker find libraries in modules: export LDFLAGS=$(echo $LD_LIBRARY_PATH | sed 's/^/-L/; s/:/ -L/g') ./configure "$BLAS" "$LAPACK" --enable-BLAS-shlib --enable-R-shlib make -j 8 make check make install -- Regards, Bjørn-Helge Mevik signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Is libtiff >= 4.0.0 now required by R for TIFF support?

tiff() need the appropriate headers and libraries installed: jpeg (version 6b or later, or libjpeg-turbo) or libpng (version 1.2.7 or later) and zlib or libtiff (any recent version – 3.9.[4-7] and 4.0.[2-10] have been tested) respectively." which se

Re: [Rd] Build R with MKL and ICC

arnaud gaboury writes: > Thank you for this configuration. Nothing about openmp? I believe -mkl=parallel makes sure that all relevant libraries and switches are used. But you might want to check with the manual. All I can say is that it works. -- Regards, Bjørn-Helge Me

Re: [Rd] Build R with MKL and ICC

## -fp-model precise is needed for make check ## -wd188 removes a lot of warnings (see R Inst. & Adm. manual) We have successfully used this setup for a couple of years now. -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Build optimized R : openblas, MKL, ATLAS

arnaud gaboury writes: > On Mon, Aug 24, 2015 at 11:29 AM, Bjørn-Helge Mevik > >> We regularly build the standard R against MKL, simply using > > Do you use proprietary Intel MKL or open source package like OpenBLAS ? As I wrote: MKL. -- Regards,

Re: [Rd] Build optimized R : openblas, MKL, ATLAS

ot; export FFLAGS="$fast -fp-model precise" export CXX="icpc" export CXXFLAGS="$fast -fp-model precise" export FC="ifort" export FCFLAGS="$fast -fp-model precise" -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?

Duncan Murdoch writes: > On 12/12/2014, 4:12 AM, Bjørn-Helge Mevik wrote: >> Duncan Murdoch writes: >> >>> users of other languages may want to have messages and variable names >>> in their native language, and ASCII might not be enough for that. >>

Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?

mes is dangerous. -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] How to best implement package options?

ain, users need to relate to separate options interfaces, but the package authors don't have to "reinvent the wheel". What is considered "best practice" for implementing package options? Any of the above, or something different? -- RegaRds, Bjørn-Helge Mevik ___

Re: [Rd] Alternative to eval(cl, parent.frame()) ?

Ah. Of course! -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Alternative to eval(cl, parent.frame()) ?

Currently, mvr() doesn't need the unevaluated arguments, but if it were to, this would be a problem. Is there an 'R best practice' for achieving what I want (several versions of the same function, with different default value for an argument)? -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] --enable-R-shlib and external BLAS/LAPACK libraries

b9000) libintlc.so.5 => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libintlc.so.5 (0x7ff526b6a000) libc.so.6 => /lib64/libc.so.6 (0x7ff5267d7000) /lib64/ld-linux-x86-64.so.2 (0x00344520) libtinfo.so.5 =&

[Rd] Tip for removing -c99 when compiling with icc

just fine. (Please don't hesitate to let me know if this is a bad idea. :-) -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] --enable-BLAS-shlib conflict with --with-lapack in configure?

Thank you for the advice! -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] --enable-BLAS-shlib conflict with --with-lapack in configure?

ot;-L/something...". > If you are concerned about performance you definitely do not want to use > shared R, not a shared BLAS. I'm sorry, I don't quite follow you here. Do you mean not create a shared R and not create a shared BLAS, or

[Rd] --enable-BLAS-shlib conflict with --with-lapack in configure?

: cannot find -lRblas (Removing the --enable-R-shlib does not make a difference in this respect.) Is this intentional or a bug? Am I doing something wrong here? -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem building R packages on RHEL 4 Linux with Intel compilers

ven't figured out how to solve, is how to also generate the libRblas.so and libRlapack.so; --enable-BLAS-shlib seems to interfer with the --with-lapack, such that the extarnal library will not be used. -- Regards, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Advice on compiling R using Intel Compilers? Btw: -c99 is deprecated

"Joris @ VU" <[EMAIL PROTECTED]> writes: > 4: ./configure --enable-R-shlib [...] > 2) Did I setup my config.site right for my system (assuming I want to > use Intel's MKL using Shared-BLAS), is it suboptimal or plain wrong? > And how can I easily test this? I don't think configure will use the ex

Re: [Rd] request for addition to R-int

ted code gives indentation steps of 4 in R code. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] When to use LazyLoad, LazyData and ZipData?

Prof Brian Ripley wrote: > On Wed, 14 Nov 2007, Bjørn-Helge Mevik wrote: > >> When should one specify LazyLoad, LazyData, and ZipData? > > Preferably always, and I would suggest all should be 'yes' if your > package will work with them. Thank you! After reading

Re: [Rd] When to use LazyLoad, LazyData and ZipData?

Duncan Murdoch wrote: > On 11/14/2007 7:01 AM, Bjørn-Helge Mevik wrote: > >> When should one specify LazyLoad, LazyData, and ZipData? > > I think that you shouldn't care about these things, and should accept > the default for them unless one of those two pieces of adv

[Rd] When to use LazyLoad, LazyData and ZipData?

g uses the methods package, specify LazyLoad: yes, and 2) The optional ZipData field controls whether the automatic Windows build will zip up the data directory or no: set this to no if your package will not work with a zipped data directory. -- Sincerely, Bjørn-H

Re: [Rd] R 2.6.0 S4 data breakage, R _data_class(), class<-, etc.

1) "too short" > + else TRUE > + }) Well, you _have_ designed a class with an invalid prototype (as determined by your own validity function). :-) -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] as.missing

s is: > g() TRUE[1] 1 I.e., when x is missing in g, and g calls f(3,x), f will use its default value for x. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] poly(*,*) in lm() (PR#8972)

_orthogonal_ polynomials, which are not the same as 1, x, x^2, etc. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Dropping dimnames doesn't matter (anymore)?

h current R versions that the overhead of keeping the dimnames through calculations is negligible? -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] make check of R-alpha_2006-04-08_r37675 fails: qbeta

S main contrib non-free deb http://security.debian.org/ sarge/updates main contrib non-free Why am I seeing older versions than you? I just installed gcc-3.4, but gcc --version still says 3.3.5. What have I done (probably without knowing it) to `insist on using gcc 3.3.*', and how ca

Re: [Rd] make check of R-alpha_2006-04-08_r37675 fails: qbeta

ow tried with ./configure CFLAGS="-g [-O|-O2|-O3] [-std=gnu99]", i.e. with every combination from "-g" to "-g -O3 -std=gnu99". The error occured if and only if -O2 or -O3 was used. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] make check of R-alpha_2006-04-08_r37675 fails: qbeta

is? 1 (0) $ gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR P

[Rd] make check of R-alpha_2006-04-08_r37675 fails: qbeta

t of tests/d-p-q-r-tests.Rout.fail: > ## Check q*(p* ( log ), log) = identity > All.eq(Rbeta, qbeta(log(Pbeta), shape1 = .8, shape2 = 2, log=TRUE)) [1] TRUE Warning message: full precision was not achieved in 'qbeta' Please let me know if there is more I can provide to help t

Re: [Rd] R-beta: configure problem (tcltk) on 64 bit Red Hat EL

nately you have removed the crucial parts of where your > configure got the configuration info from. Typically me! :-) Thanks, both of you! -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R-beta: configure problem (tcltk) on 64 bit Red Hat EL

he intended behaviour of configure. -- Sincerely, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] How to implement package-specific options?

-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] challenge: using 'subset = ' inside function ..

0), na.action = na.action)) mf } It seems to work for me: > mydata <- data.frame(y = rep(c(-1, 1), each = 5), x = rnorm(10)) > tst(y ~ x, data = mydata) subsetting expression: y > 0 or y > 0 y x 6 1 0.9568283 7 1 0.116

Re: [Rd] R crashes for large formulas in lm() (PR#8180)

status major2 minor1.1 year 2005 month06 day 20 language R The OS is Debian 3.1, the machine has 512MB RAM, and R was compiled "out of the box" from the official sources.