Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
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. Allowing for messages in non-ASCII encodings would probably be a good idea, but I think allowing non-ASCII variable names is dangerous. -- 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. >> >> Allowing for messages in non-ASCII encodings would probably be a good >> idea, but I think allowing non-ASCII variable names is dangerous. > > Dangerous in what way? Perhaps "dangerous" is a little too strong, but it opens up possibilities for problems with sharing code or running it on other systems. Also, judging by the many files I've seen (and created myself :) with a mixture of iso8859-1 and utf8, or with "double-encoded" utf8, it is surprisingly easy to make encoding mistakes when editing or processing files. And as Jan Kim wrote, you could get things that look similar but are different. -- 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: > - Intel MKL: this is part of Intel Parallel Studio and is a paid > software. Now, there is the MKL package distributed by > Revolutionanalytics, but I am not certain how this can be distributed > for free. Is there any kind of difference? In case of use of this > package, do I need to install RRO or can I just build R from GNU > against these libraries? We regularly build the standard R against MKL, simply using ./configure --with-blas='-mkl=parallel' --with-lapack --enable-BLAS-shlib (The --enable-BLAS-shlib is not strictly needed for building agains MKL.) We also try to optimise the build by setting some environment variables before running configure: fast="-ip -O3 -opt-mem-layout-trans=3 -xHost -mavx" export CC="icc" export CFLAGS="$fast -wd188 -fp-model precise" export F77="ifort" 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] 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, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build R with MKL and ICC
arnaud gaboury writes: > After a few days of reading and headache, I finally gave a try at > building R from source with Intel MKL and ICC. Documentation and posts > on this topic are rather incomplete, sometime fantasist et do not give > much explanations about configure options. > As I am not sure if mine is correct, I would appreciate some advices and > hints. This is how we build R with the Intel compilers and MKL on CentOS 6.x, with different versions of R (latest version: 3.2.1) and Intel compilers (latest version: 2015.3) on Intel SandyBridge CPUs: fast="-ip -O3 -opt-mem-layout-trans=3 -xHost -mavx" export CC="icc" export CFLAGS="$fast -wd188 -fp-model precise" export F77="ifort" export FFLAGS="$fast -fp-model precise" export CXX="icpc" export CXXFLAGS="$fast -fp-model precise" export FC="ifort" export FCFLAGS="$fast -fp-model precise" ./configure --prefix=$destdir --with-blas='-mkl=parallel' --with-lapack --enable-BLAS-shlib ## Notes (they might not be true anymore): ## -static and -ipo break compilation ## -no-prec-div breaks make check ## -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 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 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
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: fast="-ip -O3 -opt-mem-layout-trans=3 -xHost -mavx" export CC="icc" export CFLAGS="$fast -wd188 -fp-model precise" export F77="ifort" export FFLAGS="$fast -fp-model precise" export CXX="icpc" export CXXFLAGS="$fast -fp-model precise" export FC="ifort" export FCFLAGS="$fast -fp-model precise" ./configure --with-blas='-mkl=parallel' --with-lapack --enable-R-shlib (in addition, paths to the intel compilers and librareis are set up). The output from configure says: Interfaces supported: X11, tcltk External libraries:readline, BLAS(generic), LAPACK(in blas) Additional capabilities: PNG, JPEG, TIFF, NLS, cairo Options enabled: shared R library, R profiling, Java After make install, we get a libR.so linked to MKL libraries (see below for details). Am I correct in assuming that this R will use the intel MKL libraries for BLAS and LAPACK routines? (That would be very nice, because we want to use the fast libraries, but some of our uses need to have libR.so, so up to now, we've had to build to versions of R.) # ldd libR.so linux-vdso.so.1 => (0x7ff52bcf8000) libifport.so.5 => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libifport.so.5 (0x7ff52b47d000) libifcore.so.5 => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libifcore.so.5 (0x7ff52b238000) libimf.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libimf.so (0x7ff52ae6d000) libsvml.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libsvml.so (0x7ff52a6f3000) libm.so.6 => /lib64/libm.so.6 (0x7ff52a45a000) libirc.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libirc.so (0x7ff52a30b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7ff52a0ee000) libdl.so.2 => /lib64/libdl.so.2 (0x7ff529ee9000) libreadline.so.6 => /lib64/libreadline.so.6 (0x7ff529ca6000) librt.so.1 => /lib64/librt.so.1 (0x7ff529a9e000) libmkl_intel_lp64.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/mkl/lib/intel64/libmkl_intel_lp64.so (0x7ff5292b7000) libmkl_intel_thread.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/mkl/lib/intel64/libmkl_intel_thread.so (0x7ff528238000) libmkl_core.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/mkl/lib/intel64/libmkl_core.so (0x7ff5271c2000) libiomp5.so => /cluster/software/VERSIONS/intel-2011.10/composer_xe_2011_sp1/lib/intel64/libiomp5.so (0x7ff526ecf000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff526cb9000) 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 => /lib64/libtinfo.so.5 (0x7ff5265b6000) -- 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()) ?
Dear developeRs,
I maintain a package 'pls', which has a main fit function mvr(), and
functions plsr() and pcr() which are meant to take the same arguments as
mvr() and do exactly the same, but have different default values for the
'method' argument. The three functions are all exported from the name
space.
In the 'pre namespace' era, I took inspiration from lm() and implemented
it like this:
plsr <- function(..., method = pls.options()$plsralg) {
cl <- match.call()
cl$method <- match.arg(method, c("kernelpls", "widekernelpls", "simpls",
"oscorespls", "model.frame"))
cl[[1]] <- as.name("mvr")
res <- eval(cl, parent.frame())
...
Recently, Prof. Brian Ripley kindly pointed out that this doesn't work
properly when the 'pls' package in not attached:
> data(yarn, package='pls')
> pls::plsr(density ~ NIR, 6, data = yarn, validation = "CV")
Error in eval(expr, envir, enclos) : could not find function "mvr"
I first believed that
cl[[1]] <- as.name("pls::mvr")
would fix the problem, but that did not help. I have found that the
following seems to work:
plsr <- function(..., method = pls.options()$plsralg) {
cl <- match.call()
cl$method <- match.arg(method, c("kernelpls", "widekernelpls", "simpls",
"oscorespls", "model.frame"))
arguments <- as.list(cl)[-1]
res <- do.call(mvr, arguments, envir = parent.frame())
...
However, if I understand correctly, this will evaluate the arguments
before handing them over to mvr(). 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
Re: [Rd] Alternative to eval(cl, parent.frame()) ?
peter dalgaard writes:
> We discussed this recently, and I believe the winner was
>
> cl[[1]] <- quote(pls::mvr)
Thank you!
> (notice that :: is an operator, so this is profoundly different from
> as.name("pls::mvr"), which is a symbol with two colons inside!)
Ah. Of course!
--
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?
Dear developeRs,
I have a package, pls, that implements package options. The users are
supposed to use a function pls.options() to manipulate them.
If a user changes the options, they are stored in .GlobalEnv. I was
recently informed that this is against current CRAN submission policies,
so I need to change that.
I have looked at several different packages that implement package
options, and found that:
1) Many packages simply use the global R options, setting default
options with base::options() inside either .onLoad() or .onAttach().
Users then are supposed to use base::options() etc. for manipulating
the options.
This has the advantages that users can use the standard options
interface, and the package authors don't need to "reinvent the wheel".
One disadvantage is the possibility for name collisions between
package options. Some packages try to minimise that risk by prefixing
all options with the package name.
2) Some packages implement their own version of options() (like
pls.options()), and store a list of options in the package name space.
This avoids any name collisions, but users have to relate to several
options interfaces (the ones I've seen work mostly the same as the
standard options(), though).
AFAIK, this solution neccessitates calling unlockBinding() on the
option list, or using assignInMyNamespace() to update it.
3) Finally, I've found one package ('pkgmaker') that implements a
general mechanism that can be used by other packages to create package
options. The mechanism creates options()-like functions in the
package's name space, and the optins are either stored as a single
option in base:::.Options, or in the created function's enclosure.
Again, 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.missing
Gabor Grothendieck wrote:
> This is what I get:
>
>> as.missing <- force
>> f <- function(y, x=1) {cat(missing(x)) ; x}
>> g <- function(x=as.missing()) f(3,x)
>> g()
> FALSEError in as.missing() : argument "x" is missing, with no default
>> traceback()
> 3: as.missing()
> 2: f(3, x)
> 1: g()
>> traceback()
> 3: as.missing()
> 2: f(3, x)
> 1: g()
>
> so g did in fact pass the missing to f and it was only f that blew up,
> not g. If that's not what you want please explain.
I _think_ what he wants 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] R 2.6.0 S4 data breakage, R _data_class(), class<-, etc.
Martin Morgan wrote:
> But both 'new' and 'as' appear to produce invalid (in a different
> sense, I guess) objects:
>
>> setClass("snp", contains="raw",
> + validity=function(object) {
> + if (length(object) < 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
[Rd] When to use LazyLoad, LazyData and ZipData?
Dear developeRs, I've searched the documentation, FAQ, and mailing lists, but haven't found the answer(*) to the following: When should one specify LazyLoad, LazyData, and ZipData? And what is the default if they are left unspecified? (*)Except that 1) If the package you are writing 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-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?
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 advice applies
> to you. Let the package install code decide on what values to use.
Thank you. That seems like a reasonable strategy. :-)
The only small `snag' I can see is how to document the usage of data
sets. As I understand from `Writing R Extensions' (`The \usage entry
is always bar or (for packages which do not use lazy-loading of data)
data(bar).') It is preferrable to use \usage{bar} when LazyData is
true, and \usage{data(bar)} otherwise. Since data(bar) always works,
I guess the best strategy (when leaving LazyData to its default) is to
use \usage{data(bar)}.
> If you want to know the current defaults, look at the INSTALL script
> in R_HOME/bin,
Ah. I should have thought about that. :-)
--
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 this, and the very nice R-news article pointed to by Gabor Grothendieck, I've switched to specifying the directives in my packages. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] request for addition to R-int
Ben Bolker wrote: > http://cran.r-project.org/doc/manuals/R-ints.html#R-coding-standards > > gives detailed advice on how to set the indentation level for > C code to 4, but it took me a bit of poking around in the archives > to find the > > (setq ess-indent-level 4) > > incantation for getting the R indentation right as well. I'm confused. Doesn't the suggested code (add-hook 'ess-mode-hook (lambda () (ess-set-style 'C++) ... implicitly set ess-indent-level to 4? At least for me, using the suggested 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] 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 external BLAS/LAPACK libraries without supplying --with-blas=something --with-lapack=someotherthing. As I understand, if BLAS/LAPACK is not listed in the " External libraries:" line of the configure output, make will use R's own BLAS/LAPACK. (You can also check with ldd R-2.7.0/lib/libR.so after make.) -- B/H __ 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
"Mark Kimpel" <[EMAIL PROTECTED]> writes: > I would like to build R and packages with the Intel 10.1 compilers in RHEL4. We are successfully building R and packages with the Intel 10.1 compilers on RHEL4 (except a few packages, which will not compile with 10.1, but with 9.1). We also use the Intel MKL blas/lapack libraries. This is out procedure for building R: export CC="icc" export CFLAGS="-O3 -ip -wd188" export F77="ifort" export FFLAGS="-O3 -ip" export CXX="icpc" export CXXFLAGS="-O3 -ip" export FC="ifort" export FCFLAGS="-O3 -ip -mp" ./configure --prefix="/site/VERSIONS/R-2.7.0" \ --with-blas="-L/site/intel/cmkl/8.1/lib/em64t -lmkl -lvml -lguide -lpthread" \ --with-lapack="-L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl" \ --enable-R-shlib make -j 4 make -j 4 check # NB! "-j 4" won't work on all versions of R make install Packages are installed with install.packages() in R. The procedure is loosely based on the Intel/MKL examples given in the R Installation and Administration Manual. The only thing we haven'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
[Rd] --enable-BLAS-shlib conflict with --with-lapack in configure?
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 \ --with-blas="-L/site/intel/cmkl/8.1/lib/em64t -lmkl -lvml -lguide -lpthread" \ --with-lapack="-L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl" \ --enable-R-shlib [...] External libraries:readline, BLAS(generic), LAPACK(generic) Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: shared R library, R profiling, Java However, if I add --enable-BLAS-shlib, the external LAPACK will not be used: ./configure \ --with-blas="-L/site/intel/cmkl/8.1/lib/em64t -lmkl -lvml -lguide -lpthread" \ --with-lapack="-L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl" \ --enable-R-shlib --enable-BLAS-shlib [...] checking for zgeev_ in -L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl... no checking for zgeev_ in -llapack... no [...] External libraries:readline, BLAS(generic) Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: shared R library, shared BLAS, R profiling, Java >From config.log, it seems configure is trying to link with libRblas when testing for LAPACK -- but that has not been built yet: configure:37825: checking for zgeev_ configure:37889: gcc -std=gnu99 -o conftest -g -O2 -fpic -I/usr/local/include -L/usr/local/lib64 conftest.c -L$(R_HOME)/lib$(R_ARCH) -lRblas -lg2c -lm -ldl -lm >&5 /usr/bin/ld: cannot find -lRblas [...] configure:37924: checking for zgeev_ in -L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl configure:37962: gcc -std=gnu99 -o conftest -g -O2 -fpic -I/usr/local/include -L/usr/local/lib64 conftest.c -L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl -L$(R_HOME)/lib$(R_ARCH) -lRblas -lg2c -lm -ldl -lm >& 5 /usr/bin/ld: cannot find -lRblas [...] configure:37993: checking for zgeev_ in -llapack configure:38036: gcc -std=gnu99 -o conftest -g -O2 -fpic -I/usr/local/include -L/usr/local/lib64 conftest.c -llapack -L$(R_HOME)/lib$(R_ARCH) -lRblas -lg2c -lm -ldl -lm >&5 /usr/bin/ld: 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] --enable-BLAS-shlib conflict with --with-lapack in configure?
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > This is intentional. Ok. > Please note what the R-admin manual says about > --with-lapack, including 'definitely *not* recommended' Oh. I have always understood that as referring to --with-lapack, not --with-lapack="-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 was there a "not" too many? -- 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
[Rd] Tip for removing -c99 when compiling with icc
Dear developeRs, As of icc 10, the -c99 option is deprecated, and generates a lot of warnings when compiling R or R packages. If you use CC="icc -std=c99" instead of just CC="icc", R's configure will not add the -c99 option, and the code seems to compile and run 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] R crashes for large formulas in lm() (PR#8180)
Peter Dalgaard wrote: > You could still have a point, but with 255^2 terms (all but 255 of > which will be redundant since x^2 == x:x == x in modeling language). > Presumably someone thought that noone in their right mind would > specify 65000 terms... I don't think this is a fixed limit on the number of terms: On "my" R (see below), set.seed(123) x1 <- runif(1000) x2 <- runif(1000) x3 <- runif(1000) x4 <- runif(1000) x5 <- runif(1000) x6 <- runif(1000) x7 <- runif(1000) x8 <- runif(1000) x9 <- runif(1000) x10 <- runif(1000) y <- rnorm(1000) fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8*x9)^2) works fine, but fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8*x9*x10)^2) crashes. > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu 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. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] challenge: using 'subset = ' inside function ..
Hmm.. Maybe I'm overlooking something, but why not use do.call()?
For instance
tst <- function(formula, data, na.action = na.omit) {
stopifnot(inherits(formula,"formula"), length(formula) == 3)
## I want to fit a model to those observations that have 'Y > 0'
## where 'Y' is the left-hand-side (LHS)
## The really natural problem is using 'subset'; since I want to keep
'data' intact
## It's really lm(), glm(), gam(), ... but the problem is with model.frame:
cat("subsetting expression: ")
print(substitute(Y > 0, list(Y = formula[[2]])))# is perfect
YY <- formula[[2]]
cat(" or "); print(bquote(.(YY) > 0))
mf <- do.call("model.frame", list(formula = formula, data = data,
subset = bquote(.(YY) > 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.1166081
8 1 -0.9592458
9 1 -0.0974119
10 1 0.2217222
--
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?
Dear developeRs, What is the preferred way to implement package-specific options? Should one simply use options() -- e.g. options(myoption = myvalue)? (And how should one document such options?) Or is it better to implement a separate mechanismn, perhaps something like ps.options()? -- 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
Dear developeRs, I use Red Hat Enterprise Linux WS release 4 (Nahant Update 2) on an x86_64 machine (two Intel P4 CPUs with 64 bit support), and R-beta_2005-12-12_r36712.tar.gz. If I run configure without any options, it does not list tcltk among the supported interfaces: ./configure [...] R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory:/usr/local C compiler:gcc -g -O2 C++ compiler: g++ -g -O2 Fortran compiler: g77 -g -O2 Interfaces supported: X11 External libraries:readline, BLAS(generic) Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: R profiling Recommended packages: yes It seems to find tcl and tk, but not be able to compile/link them: [...] checking /usr/include/tcl.h usability... yes checking /usr/include/tcl.h presence... yes checking for /usr/include/tcl.h... yes [...] checking /usr/include/tk.h usability... yes checking /usr/include/tk.h presence... yes checking for /usr/include/tk.h... yes checking whether compiling/linking Tcl/Tk code works... no Looking in config.log, it seems that even though libX11 has been found in /usr/X11R6/lib64, it is not searched for in that directory when testing compiling/linking Tcl/Tk: configure:35654: checking for X configure:35892: result: libraries /usr/X11R6/lib64, headers /usr/X11R6/include configure:36088: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -ldl -lm -L/usr/X11R6/lib64 -lX11 >&5 configure:36094: $? = 0 configure:36098: test -z || test ! -s conftest.err configure:36101: $? = 0 configure:36104: test -s conftest configure:36107: $? = 0 [...] configure:38437: checking whether compiling/linking Tcl/Tk code works configure:38480: gcc -o conftest -g -O2 -I/usr/local/include -I/usr/include -I/usr/include -I/usr/X11R6/include -L/usr/local/lib64 conftest.c -ldl -lm -L/usr/lib -ltcl8.4 -L/usr/lib -ltk8.4 -L/usr/X11R6/lib -lX11 >&5 /usr/bin/ld: skipping incompatible /usr/lib/libtcl8.4.so when searching for -ltcl8.4 /usr/bin/ld: skipping incompatible /usr/lib/libtcl8.4.so when searching for -ltcl8.4 /usr/bin/ld: skipping incompatible /usr/lib/libtk8.4.so when searching for -ltk8.4 /usr/bin/ld: skipping incompatible /usr/lib/libtk8.4.so when searching for -ltk8.4 /usr/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status configure:38486: $? = 1 Running ./configure LDFLAGS="-L/usr/local/lib64 -L/usr/X11R6/lib64" solves/avoids the problem for me. I thought I'd report the problem anyway, since I don't know if it is the intended behaviour of configure. -- Sincerely, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-beta: configure problem (tcltk) on 64 bit Red Hat EL
Martyn Plummer wrote:
> It looks like you have the i386 RPMs for tcl and tk installed.
You are right. I have both the i386 and x86_64 RPMs installed.
> ./configure --with-tcl-config=/usr/lib64/tclConfig.sh \
> --with-tk-config=/usr/lib64/tkConfig.sh
Thank you! This works like a charm.
Prof Brian Ripley wrote:
> It is a problem with your particular OS,
You are right. As Martyn suggested, configure picked up
/usr/lib/{tcl,tk}Config.sh instead of /usr/lib64/{tcl,tk}Config.sh
because I have both i386 and x86_64 versions of the RPMs installed.
> Unfortunately 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] make check of R-alpha_2006-04-08_r37675 fails: qbeta
make check of R-alpha_2006-04-08_r37675 fails on Debian GNU/Linux 3.1 running
on an Intel P4 computer.
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status alpha
major 2
minor 3.0
year 2006
month 04
day08
svn rev37675
language R
version.string Version 2.3.0 alpha (2006-04-08 r37675)
I'm using ATLAS with the SSE2 extensions, and get the same error with ATLAS
3.2.1 (packages atlas2-* 3.2.1ln-15 in Debian) and 3.6.0 (packages atlas3-*
3.6.0-19 in Debian). I've also tried without external BLAS (--without-blas),
but the error still occurs.
43 (0) $ ./configure
[...]
R is now configured for i686-pc-linux-gnu
Source directory: .
Installation directory:/usr/local
C compiler:gcc -g -O2 -std=gnu99
Fortran 77 compiler: g77 -g -O2
C++ compiler: g++ -g -O2
Fortran 90/95 compiler:g77 -g -O2
Interfaces supported: X11, tcltk
External libraries:readline, BLAS(ATLAS)
Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
Options enabled: R profiling
Recommended packages: yes
44 (0) $ make
[...]
45 (0) $ make check
[...]
running code in 'd-p-q-r-tests.R' ... OK
comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...777,778d776
< Warning message:
< full precision was not achieved in 'qbeta'
make[3]: *** [d-p-q-r-tests.Rout] Error 1
[...]
46 (0) $ diff tests/d-p-q-r-tests.Rout.{save,fail}
3c3
< Version 2.3.0 alpha (2006-04-03 r37628)
---
> Version 2.3.0 alpha (2006-04-08 r37675)
791a792,793
> Warning message:
> full precision was not achieved in 'qbeta'
1073c1075
< Time elapsed: 2.53 0.03 2.55 0 0
---
> Time elapsed: 4.939 0.024 4.967 0 0
The (hopefully) interesting part 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 trace this!
--
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
Prof Brian Ripley wrote: > I am not seeing it on my platforms (FC3 x86_64 and i686 Linux with gcc > 3.4.5 and 4.1.0, i386 Windows and Solaris, with various compilers) and > the zero-finder changes postdate r37675 (and qbeta does not use it). I > think several other people are testing i686 Debian, including the > daiuly CRAN package checks > > I suspect it is a real (and long-standing) problem of loss of accuracy > (2.2.1 did a check but did not report the results: it seems to be a > convergence failure looking at qbeta.c). What compiler version is > this? 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 PURPOSE. -- 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
Peter Dalgaard wrote: > I don't see it with a current version either. What happens if you > reduce the optimization level? (I've tried both "-g" and -g "-O3"). > Is that -std=gnu99 bit necessary? My gcc is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13). I've now 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
Dirk Eddelbuettel wrote: > Fair point, especially as you have to insist on using gcc 3.3.* on Debian: > -- 3.3.6 is the current 3.3.* one whereas Bjørn-Helge used 3.3.5 > -- 3.4.5 is the latest 3.* one supplanting 3.3.(5,6) > -- 4.0.3 is the current default > -- 4.1.0 is available too > > That appears to be the same on Debian testing and unstable. > > Dirk > > [EMAIL PROTECTED]:~> dpkg -l | grep gcc | cut -c -78 > ii gcc 4.0.2-2The GNU C > ii gcc-2.95 2.95.4-22 The GNU C > ii gcc-3.3 3.3.6-13 The GNU C > ii gcc-3.3-base 3.3.6-13 The GNU C > ii gcc-3.4 3.4.5-2The GNU C > ii gcc-3.4-base 3.4.5-2The GNU C > ii gcc-4.0 4.0.3-1The GNU C > ii gcc-4.0-base 4.0.3-1The GNU C > ii gcc-4.1-base 4.1.0-1The GNU C > ii libgcc1 4.1.0-1GCC suppo > [EMAIL PROTECTED]:~> Hmmm... I don't `see' all those versions. After an `aptitude update': 9 (1) $ aptitude search gcc [...] i gcc - The GNU C compiler i gcc-2.95- The GNU C compiler p gcc-2.95-doc- Documentation for the GNU compilers (gcc, v gcc-3.0 - v gcc-3.0-base- v gcc-3.0-doc - v gcc-3.2 - v gcc-3.2-base- v gcc-3.2-doc - i A gcc-3.3 - The GNU C compiler i A gcc-3.3-base- The GNU Compiler Collection (base package p gcc-3.3-doc - Documentation for the GNU compilers (gcc, i gcc-3.4 - The GNU C compiler i A gcc-3.4-base- The GNU Compiler Collection (base package p gcc-3.4-doc - Documentation for the GNU compilers (gcc, [...] The 3.3 is 3.3.5-13, and the 3.4 is 3.4.3-13. My /etc/apt/sources.list is: deb http://ftp.no.debian.org/debian/ sarge main non-free contrib deb-src http://ftp.no.debian.org/debian/ sarge main non-free contrib deb http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free deb-src http://ftp.no.debian.org/debian-non-US sarge/non-US 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 can I reverse that? (I have no desire to use old compiler versions. :-) -- 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)?
In the "old days", one way of speeding up matrix calculations was to drop the dimnames of the matrices prior to the calculations, i.e., dimnames(X) <- NULL. I distinctly remember that this could have a great impact at least in Splus 3.x (under UNIX/Linux). I just did a small, informal test of this with a couple of functions I use to fit plsr models, in R 2.3.0 (Linux). It didn't seem to have any effect at all (the functions actually ran a tiny bit slower, probably due to the "dimnames(X) <- NULL" command). Is the "general rule-of-thumb" with 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] poly(*,*) in lm() (PR#8972)
> I used the function lm() to calculate the coefficients of a polynome. If I > used > the function poly(t,2) to denote a polynome of form 1 + x + x^2, the > coefficients are wrong. If you take a look at the manual page for poly, you will find that poly (by default) will calculate _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] Is libtiff >= 4.0.0 now required by R for TIFF support?
We recently discovered that since R 3.3.0, on our CentOS 6 based
cluster, R gets built without TIFF support. The last version where TIFF
support was built, was 3.2.5.
We have libtiff 3.9.4 installed:
$ rpm -q libtiff-devel
libtiff-devel-3.9.4-21.el6_8.x86_64
(Since CentOS 6 is so old, we have manually installed newer versions of
some dependencies: curl 7.46.0, zlib 1.2.8, bzip2 1.0.6, xz 5.2.2 and
pcre 8.38.)
We configure R like this:
BLAS=--with-blas='-mkl=parallel'
LAPACK=--with-lapack
./configure --prefix=$destdir "$BLAS" "$LAPACK" --enable-BLAS-shlib
--enable-R-shlib
(and build with Intel compilers.)
The tiff-related output of the configure script in R 3.2.5 was
$ grep -i tiff _log_3.2.5
checking tiffio.h usability... yes
checking tiffio.h presence... yes
checking for tiffio.h... yes
checking for TIFFOpen in -ltiff... yes
Additional capabilities: PNG, JPEG, TIFF, NLS, cairo
Beginning with R 3.3.0, it was just
$ grep -i tiff _log_3.3.0
Capabilities skipped: TIFF, ICU
(This has been the output for all versions we've installed since 3.3.0.)
I looked at the configure script, and in 3.2.5, the tests for libtiff
starts like this (I've adjusted the indentation):
if test "${use_libtiff}" = yes; then
for ac_header in tiffio.h
do :
ac_fn_c_check_header_mongrel "$LINENO" "tiffio.h"
"ac_cv_header_tiffio_h" "$ac_includes_default"
if test "x$ac_cv_header_tiffio_h" = xyes; then :
cat >>confdefs.h <<_ACEOF
#define HAVE_TIFFIO_H 1
_ACEOF
From 3.3.0 on, it starts like this (with indentation adjusted):
if test "${use_libtiff}" = yes; then
mod=
## pkg-config support was introduced in libtiff 4.0.0
## I guess the module name might change in future, so
## program defensively here.
if "${PKGCONF}" --exists libtiff-4; then
mod=libtiff-4
fi
if test -n "${mod}"; then
save_CPPFLAGS=${CPPFLAGS}
TIF_CPPFLAGS=`"${PKGCONF}" --cflags ${mod}`
CPPFLAGS="${CPPFLAGS} ${TIF_CPPFLAGS}"
for ac_header in tiffio.h
do :
ac_fn_c_check_header_mongrel "$LINENO" "tiffio.h"
"ac_cv_header_tiffio_h" "$ac_includes_default"
if test "x$ac_cv_header_tiffio_h" = xyes; then :
cat >>confdefs.h <<_ACEOF
#define HAVE_TIFFIO_H 1
_ACEOF
And all the rest of the tests for libtiff are within the "if test -n
"${mod}"; then" branch. As I read it, this means that if you don't have
libtiff >= 4.0.0 installed, the tests for libtiff will not be run, and
support for TIFF disabled.
On the other hand, Appendix A.2 "Useful libraries and programs" in
https://cran.r-project.org/doc/manuals/r-release/R-admin.html says
"The bitmapped graphics devices jpeg(), png() and 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 seems to imply that libtiff 3.9.4 should be fine.
Is there a bug in the configure script, is the "R Installation and
Administration" not up to date, or is it me that misunderstands
something here?
--
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
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
Ryan Novosielski writes:
> Hi there,
>
> I initially asked about this on r-help and was told this might be a better
> venue. I’m not really convinced from reading the posting guide, but I’ll give
> it a shot. It was also suggested that the R-Project doesn’t really care about
> building with “non-standard” compilers, but I can’t find any evidence of that
> on the website (indeed, there’s some mention of successful past builds, and
> the build itself is successful).
>
> I built R 4.0.2 with the Intel Parallel Studio XE compiler suite, versions
> 19.0.x to 19.1.1. Build seems to go fine. I built it like this:
>
> module purge
> module load intel/19.1.1
> module list
>
> export CC=icc
> export CXX=icpc
> export F77=ifort
> export FC=ifort
> export AR=xiar
> export LD=xild
>
> export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export F77FLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export FFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export CXXFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread"
>
> VERSION=4.0.1
>
> /scratch/novosirj/install-files/R-${VERSION}/configure --with-blas="$MKL"
> --with-lapack --prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
>make -j32 && make check && make -j32 install
For what it is worth, we used to build R with the Intel compilers and
MKL on our HPC cluster (on CentOS Linux), and we used the following
setup. Note the comments about -fp-model precise and -ipo. It might no
longer be a problem, but maybe worth checking.
fast="-ip -O3 -qopt-mem-layout-trans=3 -xHost -mavx"
## Notes:
## -static and -ipo break compilation
## -no-prec-div breaks make check
## -fp-model precise is needed for make check
## -wd188 removes a lot of warnings (see R Inst. & Adm. manual)
export CC="icc"
export CFLAGS="$fast -wd188 -fp-model precise"
export F77="ifort"
export FFLAGS="$fast -fp-model precise"
export CXX="icpc"
export CXXFLAGS="$fast -fp-model precise"
export FC="ifort"
export FCFLAGS="$fast -fp-model precise"
## This 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
