search for: pairlists

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 subassign...

Hi, I seem to not be able to assign NULL to an element of a pairlist without causing it to be coerced to a plain list. For example: > x <- pairlist(1, 2) > class(x) [1] "pairlist" > x[1] <- list(NULL) > class(x) [1] "list" This actually true for all [()<- assignments regardless of list value, e.g. > x <- pairlist(1, 2) > x[1] <- list(0) [1]

Hi, ?pairlist gives no explanation about what exactly is the difference between a pairlist and a list (except that a pairlist of length 0 is 'NULL'). So, what's a pairlist? class(.Options) [1] "pairlist" Some strange things about the "pairlist" type: > showClass("pairlist") Error in getClass(Class) : "pairlist" is not a defined class

...at least I can live with having to use an explicit > as.pairlist(). > > Thanks > > Henrik > > On Wed, Oct 12, 2016 at 10:53 AM, Michael Lawrence > <lawrence.michael at gene.com> wrote: >> 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. A...

...minate 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. > > and I hope we would not go there just for the purpose of > eliminating pairlists from user code, would we ? > > As nobody else has mentioned it, I'd really like to mention the > two (actually 3) functions important for dealing with function > argument lists much more transparently than the > as.list(<function>) things below: > > formals(<f&g...

...r consistency, but if you bump into major issues, at least I can live with having to use an explicit as.pairlist(). Thanks Henrik On Wed, Oct 12, 2016 at 10:53 AM, Michael Lawrence <lawrence.michael at gene.com> wrote: > 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 >>...

...e 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. and I hope we would not go there just for the purpose of eliminating pairlists from user code, would we ? As nobody else has mentioned it, I'd really like to mention the two (actually 3) functions important for dealing with function argument lists much more transparently than the as.list(<function>) things below: formals(<f>) formals(<f>) <- &l...

...airlist from user code, which >> > suggests the alternative of allowing for function >> > arguments to be stored in lists. That's a much deeper >> > change though. >> >> and I hope we would not go there just for the purpose of >> eliminating pairlists from user code, would we ? >> >> As nobody else has mentioned it, I'd really like to mention the >> two (actually 3) functions important for dealing with function >> argument lists much more transparently than the >> as.list(<function>) things below: >&gt...

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" in this case. If others agree, I'...

Hi All, I was wondering what people thought to the idea of getting "[markdown]" added to the subject lines of all the mails to the markdown mailing list? It would certainly help me out with my email organisation. Many thanks CHEERS> SAM

Dear all, It seems that as.pairlist does not convert call objects, producing results like the following: > is.pairlist(as.pairlist(quote(x + y))) [1] FALSE Should this behavior be expected? Thanks, Jialin > sessionInfo() R version 3.4.1 (2017-06-30) Platform: x86_64-suse-linux-gnu (64-bit) Running under: openSUSE Tumbleweed Matrix products: default BLAS: /usr/lib64/R/lib/libRblas.so

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) relist(a) The help page didn't say...

the help page says: 'is.list' returns 'TRUE' iff its argument is a 'list' _or_ a 'pairlist' of 'length' > 0, whereas 'is.pairlist' only returns 'TRUE' in the latter case. does the "latter case" mean a 'pairlist' of 'length' > 0? but > is.pairlist(pairlist()) [1] TRUE > length(pairlist())

...ey [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 for many things. > ... Wouldn't it, therefore, make sense to provide a 'pairlist' package which exposes the internal pairlist structure and provides appropriate functions (car, cdr, ...), instead of expecting people to keep re-implementing these f...

Full_Name: Glen Herrmannsfeldt Version: 2.2.1 OS: Linux Submission from: (NULL) (128.95.113.77) Following the discussion in "Writing R Extensions" in section 5.8.2, there is no indication that showArgs expects a pairlist() instead of a list(). I was trying .Call("showArgs",list(one=1,two=2,three=3)) for example, and getting many core dumps. It wasn't until reading

While I empathize with your predicament, I generally prefer not to have expletives in my inbox. Also, what has this to do with markdown? On Jul 5, 2013 7:20 PM, "bowerbird" <bowerbird at aol.com> wrote: > fan_fucking_tastic. > > somebody hit another one of the dead skunks on this road. > > -bowerbird > > _______________________________________________ >

Hello, As I am using markdown to write documentation, I am often tempted to make links to terms in definition lists. Since this is not possible for now (at least in php markdown extra), I was wondering if this could be a common addition in major implementation supporting definition lists. the syntax would be term {#id} : definition This syntax tries to follows current convention and

This code which has worked for years in R but fails under R-devel: > R.version.string [1] "R Under development (unstable) (2012-07-25 r59963)" > > n <- 3 > f <- function(x) {} > formals(f) <- rep(formals(f), n) ## Error in rep(formals(f), n) : replication of pairlists is defunct The message suggests that the change was intentional. Why was this functionality removed? What code should be used in its place? -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com

...able ="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 is made up of two apparently disjoint lists: > flags_val <- c( 0,1,1,1,4,1,1,1,4,1,1,1,4,1,1,1,4,1,1) > flags_nam <- c("TrendOff","MOdwt","ZeroPadding", + "Step1HSOff","Step1NumHSOff","Step1NumHSOff&qu...

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: