[Rd] Protocol for setting default number of cores

2012-11-15 Thread Udaya B. Kogalur
We recently posted randomForestSRC on CRAN.  It uses OpenMP in the
native code extensively.  We set the default number of cores to two
(2), but we typically run it at the maximum (omp_get_max_threads())
during analysis.  Currently, users need to set options(), set an
environment variable, or edit their .Rprofile to use more than two
cores.  We followed the protocol for mc.cores in mclapply() in the
package parallel.  R CMD CHECK aside, is it acceptable to set the
default to the maximum or is this not recommended?

ubk

-- 
kogalursh...@gmail.com (preferred)
ud...@kogalur-shear.com

Phone: 919-824-9825
Fax: 919-890-3868
Website:  www.kogalur-shear.com

Udaya B. Kogalur, Ph.D.
Adjunct Staff, Dept of Quantitative Health Sciences, Cleveland Clinic Foundation
Consultant, Kogalur Shear Corporation
6887 Idols Road, Suite B
Clemmons, NC 27012

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


Re: [Rd] R-devel Digest, Vol 117, Issue 13

2012-11-15 Thread Georgi Boshnakov
Hi, 

> ... Wrong. It looks like internally a[[1]] is always used instead of a[[i]].
> The real problem it seems is that 'a' is treated as if it was of
> ength 1:
>
>  > mapply(function(x, y) {x * y}, a, 1:3)
>  [1] 101 202 303
>   > mapply(function(x, y) {x * y}, a, 5)
>   [1] 505
>
> In other words, internal dispatch works for [[ but not for length().

Documentation of mapply says 
> Arguments are recycled if necessary.

So, the function seems to work as documented. 

One may be tempted to expect that what 'length()' says should take precedence 
but  
the '...' arguments in 'mapply' are documented as
>  ...: arguments to vectorize over (vectors or lists of strictly
>  positive length, or all of zero length).

So, the defining feature is that the arguments are vectors.  
Since class A is not defined as a vector class, object 'a' is a scalar (vector 
of length 1 in R) and therefore recycled. 

It is probably not a good idea to redefine length() for class A without making 
it a subclass of 'vector' (or something equivalent) since doing so redefines a 
fundamental basic feature behind R's back. 

Best regards,
Georgi

--
Dr Georgi Boshnakov   tel: (+44) (0)161 306 3684
School of Mathematics fax: (+44) (0)161 306 3669
Alan Turing Building 1.125
The University of Manchester  email: georgi.boshna...@manchester.ac.uk
Oxford Road
Manchester M13 9PL
UK



Message: 7
Date: Wed, 14 Nov 2012 21:42:07 -0800
From: Herv? Pag?s 
To: R-devel@r-project.org
Subject: [Rd] bug with mapply() on an S4 object
Message-ID: <50a480af.1030...@fhcrc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

Starting with ordinary vectors, so we know what to expect:

   > mapply(function(x, y) {x * y}, 101:106, rep(1:3, 2))
   [1] 101 204 309 104 210 318

   > mapply(function(x, y) {x * y}, 101:106, 1:3)
   [1] 101 204 309 104 210 318

Now with an S4 object:

   setClass("A", representation(aa="integer"))
   a <- new("A", aa=101:106)

   > length(a)
   [1] 1

Implementing length():

   setMethod("length", "A", function(x) length(x@aa))

Testing length():

   > length(a)  # sanity check
   [1] 6

No [[ yet for those objects so the following error is expected:

   > mapply(function(x, y) {x * y}, a, rep(1:3, 2))
   Error in dots[[1L]][[1L]] : this S4 class is not subsettable

Implementing [[:

   setMethod("[[", "A", function(x, i, j, ...) x@aa[[i]])

Testing [[:

   > a[[1]]
   [1] 101
   > a[[5]]
   [1] 105

Trying mapply again:

   > mapply(function(x, y) {x * y}, a, rep(1:3, 2))
   [1] 101 202 303 101 202 303

Wrong. It looks like internally a[[1]] is always used instead of a[[i]].

The real problem it seems is that 'a' is treated as if it was of
length 1:

   > mapply(function(x, y) {x * y}, a, 1:3)
   [1] 101 202 303
   > mapply(function(x, y) {x * y}, a, 5)
   [1] 505

In other words, internal dispatch works for [[ but not for length().

Thanks,
H.

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:(206) 667-1319





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


[Rd] Help page on '$': 'warnPartialMatchAttr' should be 'warnPartialMatchDollar'

2012-11-15 Thread Suharto Anggono Suharto Anggono
http://stackoverflow.com/questions/6065724/assigning-value-to-a-variable-that-has-a-dot-in-the-name
 made me realize this.


The context is 'a' is assigned to ret$log.id, but then ret$log returns "a" and 
ret$l also returns "a".
There is a comment from Charles on the question:
"Also see options(warnPartialMatchDollar=T) if you want to track these."


But, in bottom part, there is Chase's answer, quoting help page for $.

... under Character indices:
Thus the default behaviour is to use partial matching only when extracting from 
recursive objects (except environments) by $. Even in that case, warnings can 
be switched on by options(warnPartialMatchAttr = TRUE).


This is what I get from R documentation of 'options'.

 ‘warnPartialMatchAttr’: logical.  If true, warns if partial
  matching is used in extracting attributes via ‘attr’.

 ‘warnPartialMatchDollar’: logical.  If true, warns if partial
  matching is used for extraction by ‘$’.


So, in the part of help page on '$' quoted in part of Chase's answer above,
options(warnPartialMatchAttr = TRUE)
should be
options(warnPartialMatchDollar = TRUE)


This is in R 2.15.2.

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