similar to: unlist on nested pairlists

Here is a description and a proposed solution for a bug in unlist(). I've used version 2.7.2 RC (2008-08-18 r46382) to look at this, under linux. unlist(recursive=TRUE) incorrectly returns a factor with zero levels when passed either a nested list of factors, or a data frame containing only factor columns. You can't print() the result. x <- list(list(v=factor("a")))

Reading the body of function 'AnswerType' in bind.c, called from 'do_c' and 'do_unlist', I notice that EXPRSXP and VECSXP are handled identically in the recurse = TRUE case. A corollary is that c(recursive = TRUE) and unlist(recursive = TRUE) treat expression vectors like expression(a, b) as lists of symbols and calls. And since they treat symbols and calls as

Dear list, I have to problems that are connected: PROBLEM 1 I wonder if it is somehow possible to patch the function 'unlist(use.names=TRUE)' such that you can specify an arbitrary name delimiter, e.g. "/" or "_". As I often name my variables "var.x.y", the default delimiter makes it hard to distinguish the distinct layers of a nested list after unlisting.

Dear list, I think I just stumbled across a bug in either 'relist()' and/or 'as.relistable()'. It seems that 'pairlists' can only be un- and relisted as long as they're not nested: Good: a <- as.relistable(as.pairlist(list(a=1, b=2))) a <- unlist(a) relist(a)# Works Bad: a <- as.relistable(as.pairlist(list(a=1, b=2, c=list(c.1=1, c.2=2)))) a <- unlist(a)

> -----Original Message----- > From: Luke Tierney [mailto:luke at stat.uiowa.edu] > R does not provide a pairlist data structure. This creates a dilemma > when translating some list-based xlispstat code, or, more > importantly, when implementing an algorithm for which parilists are > the natural data structure to use. > ... > Pairlists were and still are used internally

I would like to create a vector of pairlist (flag, binary_value) like: (variable ="TrendOff", value = 0) (variable ="MOdwt", value = 1) (variable ? "ZeroPadding", value =1) ................................................ I tried the following syntax but the emcompassing list (that I called "flags") is not made up of pairlists. Instead it

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Wed, 12 Oct 2016 15:21:13 -0700 writes: > Thanks, this was what I expected. There is a desire to > eliminate the usage of pairlist from user code, which > suggests the alternative of allowing for function > arguments to be stored in lists. That's a much deeper

On Wed, 19 Oct 2016, Henrik Bengtsson wrote: > On Sat, Oct 15, 2016 at 2:00 AM, Martin Maechler > <maechler at stat.math.ethz.ch> wrote: >>>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>>>> on Wed, 12 Oct 2016 15:21:13 -0700 writes: >> >> > Thanks, this was what I expected. There is a desire to >>

Michael, thanks for this info. I've stumbled upon this in a case where I walk an R expression (the AST) and (optionally) modifies it (part of the globals package). In R expressions, a function definition uses a pairlist to represent the arguments. For example, > expr <- quote(function(x = 1) x) > str(as.list(expr)) List of 4 $ : symbol function $ :Dotted pair list of 1 ..$ x:

I've used the HDF5 library to bring some data into R. THe verbose output looks like this: > hdf5load("hdfGraphWed_Mar_16_13_33_37_2005.hdf",load=T,verbosity=1,tidy=T) Processing object: cprSeats ...... which is a Group Processing object: Seats 0 ...... its a dataset......Finished dataset Processing object: Seats 1 ...... its a dataset......Finished dataset Processing object:

On Sat, Oct 15, 2016 at 2:00 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>>> on Wed, 12 Oct 2016 15:21:13 -0700 writes: > > > Thanks, this was what I expected. There is a desire to > > eliminate the usage of pairlist from user code, which > >

Dear r-helpers, I have a list whose elements are > str(durCut[[1]]) Ord.factor w/ 5 levels "vLow"<"low"<"med"<..: 3 2 5 2 2 2 4 4 3 5 ... How do I unlist durCut into an ordered factor? > str(unlist(durCut)) int [1:3024] 3 2 5 2 2 2 4 4 3 5 ... _____________________________ Professor Michael Kubovy University of Virginia Department of Psychology

Hi Henrik, It would help to understand your use case for pairlists. Thanks, Michael On Wed, Oct 12, 2016 at 9:40 AM, Michael Lawrence <michafla at gene.com> wrote: > The coercion is probably the most viable workaround for now, as it's > consistent with what happens internally for calls. All pairlists/calls > are converted to list for subassignment, but only calls are

Thanks, this was what I expected. There is a desire to eliminate the usage of pairlist from user code, which suggests the alternative of allowing for function arguments to be stored in lists. That's a much deeper change though. On Wed, Oct 12, 2016 at 12:31 PM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > Michael, thanks for this info. > > I've stumbled upon

It also does the same thing if the factor is not on the first level of the list, which seems to be due to the fact that the islistfactor is recursive, but if a list is a list-factor, the first level lists are coerced into character strings. > x <- list(list(factor(LETTERS[1]))) > unlist(x) Error in as.character.factor(x) : malformed factor However, if one of the factors is at the top

summary: The function 'by' inconsistently strips class from the data to which it is applied. quick reason: tapply strips class when simplify is set to TRUE (the default) due to the class stripping behaviour of unlist. quick answer: This can be fixed by invoking tapply with simplify=FALSE, or changing tapply to use do.call(c instead of unlist executable example:

I do not have access to the bug reporting system. If somebody can get me access, I can create a formal bug report. The latter issues seem like duplicates of: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=12572 (with slightly different output), but as that bug was reported nearly 10 years ago, it might be worth creating an update under R version 3. I could not find the first issue when

The coercion is probably the most viable workaround for now, as it's consistent with what happens internally for calls. All pairlists/calls are converted to list for subassignment, but only calls are converted back. My guess is that the intent was for users to move from using a pairlist to the "new" (almost 20 years ago) list. In my opinion, consistency trumps "convenience"

Reproducible example: x <- list(list(list(), list())) unlist(x) *> Error in as.character.factor(x) : malformed factor* What should happen: unlist(x) > NULL R.version platform x86_64-apple-darwin15.6.0 arch x86_64 os darwin15.6.0 system x86_64, darwin15.6.0 status major 3 minor 5.0 year 2018 month 04 day

Hi, > dd <- data.frame(A=c("b","c","a"), B=3:1) > dd A B 1 b 3 2 c 2 3 a 1 > unlist(dd) A1 A2 A3 B1 B2 B3 2 3 1 3 2 1 Someone else might get something different. It all depends on the values of its 'stringsAsFactors' option: > dd2 <- data.frame(A=c("b","c","a"), B=3:1, stringsAsFactors=FALSE) > dd2