similar to: R-alpha: (minor?) S/R inconsistency: mode(unclass(terms(...)))

In S, NULL and list() are not the same. In R they are (I think). --------------------------------------------------- At least, is.list(NULL) #-> 'F' in S; 'TRUE' in R Yes: I had an instance where this broke correct S code: match(c("xlab","ylab"), names(list(...))) when '...' is empty, gives an error in R, but gives c(NA,NA) in S.

> Henrik Bengtsson: > > I'm looking for a way to get the length of an object 'x' as given by > base data type without dispatching on class. The performance improvement you're looking for is implemented in the latest version of pqR (pqR-2016-10-24, see pqR-project.org), along with corresponding improvements in several other circumstances where unclass(x) does not

I'm looking for a way to get the length of an object 'x' as given by base data type without dispatching on class. Something analogous to how .subset()/.subset2(), e.g. a .length() function. I know that I can do length(unclass(x)), but that will trigger the creation of a new object unclass(x) which I want to avoid because 'x' might be very large. Here's a dummy example

Regarding the discussion of getting length(unclass(x)) without an unclassed version of x being created... There are already no copies done for length(unclass(x)) in pqR (current version of 2017-06-09 at pqR-project.org, as well as the soon-to-be-release new version). This is part of a more general facility for avoiding copies from unclass in other circumstances as well - eg,

On 08/24/2018 07:55 PM, Henrik Bengtsson wrote: > Is there a low-level function that returns the length of an object 'x' > - the length that for instance .subset(x) and .subset2(x) see? An > obvious candidate would be to use: > > .length <- function(x) length(unclass(x)) > > However, I'm concerned that calling unclass(x) may trigger an > expensive copy

On 09/05/2018 11:18 AM, I?aki Ucar wrote: > The bottomline here is that one can always call a base method, > inexpensively and without modifying the object, in, let's say, > *formal* OOP languages. In R, this is not possible in general. It > would be possible if there was always a foo.default, but primitives > use internal dispatch. > > I was wondering whether it would be

Hi Tomas, On 09/03/2018 11:49 AM, Tomas Kalibera wrote: > Please don't do this to get the underlying vector length (or to achieve > anything else). Setting/deleting attributes of an R object without > checking the reference count violates R semantics, which in turn can > have unpredictable results on R programs (essentially undebuggable > segfaults now or more likely later

In a real example I was trying to remove the class from the result of table, just because it was to be used as a building block for other things and a simple integer vector seemed likely to be most efficient. I'm puzzled as to why unclass doesn't work. > zed <- table(1:5) > class(zed) [1] "table" > class(unclass(zed)) [1] "array" >

In a real example I was trying to remove the class from the result of table, just because it was to be used as a building block for other things and a simple integer vector seemed likely to be most efficient. I'm puzzled as to why unclass doesn't work. > zed <- table(1:5) > class(zed) [1] "table" > class(unclass(zed)) [1] "array" >

The solution below introduces a dependency on data.table, but otherwise it does what you need: --- # special method for Foo objects length.Foo <- function(x) { length(unlist(x, recursive = TRUE, use.names = FALSE)) } # an instance of a Foo object x <- structure(list(a = 1, b = list(b1 = 1, b2 = 2)), class = "Foo") # its length stopifnot(length(x) == 3L) # get its length as

I have a little problem about method dispatch and "unnessary" copying. Basically what I would like to do is: `[.myclass` <- function(x, i,j, extraopt=TRUE/FALSE, drop=TRUE) { ...do stuff depending on extraopt... value <- Nextmethod("[", x, i,j, drop=TRUE) ... do more stuff depending on extraopt... } I have two general problems: (1) NextMethod() really

It really is unclear what is claimed to be a bug here. But see https://stat.ethz.ch/pipermail/r-devel/2007-May/045592.html for why the bug is not in R: your old and new data do not match. Your fit is to a category. [The problem with the web interface to R-bugs was reported last week: it is being worked on.] On Mon, 30 Apr 2007, r.darnell at uq.edu.au wrote: > This is a multi-part

The bottomline here is that one can always call a base method, inexpensively and without modifying the object, in, let's say, *formal* OOP languages. In R, this is not possible in general. It would be possible if there was always a foo.default, but primitives use internal dispatch. I was wondering whether it would be possible to provide a super(x, n) function which simply causes the

Please don't do this to get the underlying vector length (or to achieve anything else). Setting/deleting attributes of an R object without checking the reference count violates R semantics, which in turn can have unpredictable results on R programs (essentially undebuggable segfaults now or more likely later when new optimizations or features are added to the language). Setting attributes

Full_Name: simon wood Version: 2.2.0 (and lower) OS: linux/windows Submission from: (NULL) (86.135.153.59) I think that the documentation for the `specials' attribute of a `terms.object' is not quite right: specials: If the 'specials' argument was given to 'terms.formula' there is a 'specials' attribute, a list of vectors indicating the terms

I used read.dta() to read in a Stata 9 dataset to R. The "Sex01" variable takes on two values in Stata: 0 and 1, and it is labeled "M" and "F" respectively, analogous to an R factor. Thus, read.dta reads it in as a factor. Now, I wanted to see what this variable *really* is, in R. For instance, sometimes R converts a 0/1 variable into a 1/2 variable when it considers

Is there a low-level function that returns the length of an object 'x' - the length that for instance .subset(x) and .subset2(x) see? An obvious candidate would be to use: .length <- function(x) length(unclass(x)) However, I'm concerned that calling unclass(x) may trigger an expensive copy internally in some cases. Is that concern unfounded? Thxs, Henrik

Have I been sleeping in class? rw1071 from CRAN, windows XP incidencia is made by a call to tapply > class(incidencia) [1] "array" > incidencia <- unclass(incidencia) > class(incidencia) [1] "array" Kjetil Halvorsen

Dear R-people, recently at s-news we had a discussion about factor(). I thought you might be interested in some of my thoughts about factors. Any comments welcome Best regards Jens Oehlschlaegel-Akiyoshi ------------------------------------------------------------------- I think the problem is deeper than that factors would just be handled inapprobriately by some S+ functions, the

Perhaps someone can enlighten me here: R> x <- factor(LETTERS[1:3]) R> x [1] A B C R> mode(x) [1] "factor" R> class(x) [1] "factor" R> mode(unclass(x)) [1] "factor" S-PLUS has > x <- factor(LETTERS[1:3]) > mode(x) [1] "numeric" > class(x) [1] "factor" > mode(unclass(x)) [1] "numeric" ???