The following code seems to contain an inconsistency in
the behavior of vapply(). Am I missing something here?
## This function assumes v is a 3d vector, beta a scalar.
f3d <- function(v,beta) { v+beta }
## This expression applies f3d to a vector of scalars, and
## specifies the template 'array(1
On 04/11/2014 01:43 PM, Simon Urbanek wrote:
Greg,
On Apr 11, 2014, at 11:50 AM, Gregory R. Warnes
wrote:
Hi All,
I see this in the NEWS for R 3.1.0:
type.convert() (and hence by default read.table()) returns a
character vector or factor when representing a numeric input as a
double would
On Apr 11, 2014, at 3:47 PM, Romain Francois wrote:
> Hello,
>
> I’ve been using shrinking in
> https://github.com/hadley/dplyr/blob/master/inst/include/tools/ShrinkableVector.h
>
> This defines a ShrinkableVector of some R type (INTSXP, ...) given the
> maximum number of elements it will h
Hello,
I’ve been using shrinking in
https://github.com/hadley/dplyr/blob/master/inst/include/tools/ShrinkableVector.h
This defines a ShrinkableVector of some R type (INTSXP, ...) given the maximum
number of elements it will hold. Then, I reset with SETLENGTH when needed. The
constructor prote
Greg,
On Apr 11, 2014, at 11:50 AM, Gregory R. Warnes wrote:
> Hi All,
>
> I see this in the NEWS for R 3.1.0:
>
> type.convert() (and hence by default read.table()) returns a character vector
> or factor when representing a numeric input as a double would lose accuracy.
> Similarly for com
Hi All,
I see this in the NEWS for R 3.1.0:
type.convert() (and hence by default read.table()) returns a character vector
or factor when representing a numeric input as a double would lose accuracy.
Similarly for complex inputs.
This behavior seems likely to surprise users. Would it be possi
Kevin,
Kevin,
On Apr 10, 2014, at 4:57 PM, Kevin Ushey wrote:
> Suppose I generate an integer vector with e.g.
>
>SEXP iv = PROTECT(allocVector(INTSXP, 100));
>
> and later want to shrink the object, e.g.
>
>shrink(iv, 50);
>
> would simply re-set the length to 50, and allow R to rec
