similar to: Where does L come from?

> the lack of a decimal place had historically not been significant Version 4 of S (c. 1991) and versions of S+ based on it treated a sequence of digits without a decimal point as integer. Bill Dunlap TIBCO Software wdunlap tibco.com On Sat, Aug 25, 2018 at 4:33 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 25/08/2018 4:49 PM, Herv? Pag?s wrote: > >> The

On 25/08/2018 4:49 PM, Herv? Pag?s wrote: > The choice of the L suffix in R to mean "R integer type", which > is mapped to the "int" type at the C level, and NOT to the "long int" > type, is really unfortunate as it seems to be misleading and confusing > a lot of people. Can you provide any evidence of that (e.g. a link to a message from one of these

The choice of the L suffix in R to mean "R integer type", which is mapped to the "int" type at the C level, and NOT to the "long int" type, is really unfortunate as it seems to be misleading and confusing a lot of people. The fact that nowadays "int" and "long int" have the same size on most platforms is only anecdotal here. Just my 2 cents. H.

On Thu, 29 Jun 2023 at 01:34, Carl Boettiger <cboettig at gmail.com> wrote: > > Thanks Simon, I was very much hoping that would be the case! It may > be that I just need to put the version requirement on 4.0 then. I > will be sure to add this version restriction to my packages (which > technically I should be doing anyway since this function didn't exist > in early

On 25 August 2018 at 13:49, Herv? Pag?s wrote: | The choice of the L suffix in R to mean "R integer type", which | is mapped to the "int" type at the C level, and NOT to the "long int" | type, is really unfortunate as it seems to be misleading and confusing | a lot of people. The point I was trying to make in what you quote below is that the L may come from a time

Thanks Simon, I was very much hoping that would be the case! It may be that I just need to put the version requirement on 4.0 then. I will be sure to add this version restriction to my packages (which technically I should be doing anyway since this function didn't exist in early versions of `tools`.) Cheers, Carl --- Carl Boettiger http://carlboettiger.info/ On Wed, Jun 28, 2023 at

I noted Duncan's comment that an answer had been provided, and went to the archives to find his earlier comment, which I am fairly sure I saw a day or two ago. However, neither May nor June archives show Duncan in the thread except for the msg below (edited for space). Possibly tech failures are causing misunderstandings. JN On 14-06-02 06:00 AM, r-devel-request at r-project.org wrote: >

On 25 August 2018 at 09:28, Carl Boettiger wrote: | I always thought it meant "Long" (I'm assuming R's integers are long | integers in C sense (iirrc one can declare 'long x', and it being common to | refer to integers as "longs" in the same way we use "doubles" to mean | double precision floating point). But pure speculation on my part, so I'm |

tools::R_user_dir() provides configurable directories for R packages to write persistent information consistent with standard best practices relative to each supported operating systems for applications to store data, config, and cache information respectively. These standard best practices include writing to directories in the users home filespace, which is also specifically against CRAN policy.

Not that it brings closure, but there's also https://stat.ethz.ch/pipermail/r-devel/2017-June/074462.html Henrik On Sat, Aug 25, 2018, 06:40 Marc Schwartz via R-devel <r-devel at r-project.org> wrote: > On Aug 25, 2018, at 9:26 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > > > > Hi all, > > > > Would someone mind pointing to me to the

Herve (et al.), On Fri, May 22, 2020 at 3:16 PM Herv? Pag?s <hpages at fredhutch.org> wrote: > Gabe, > > It's the current behavior of paste() that is a major source of bugs: > > ## Add "rs" prefix to SNP ids and collapse them in a > ## comma-separated string. > collapse_snp_ids <- function(snp_ids) > paste("rs", snp_ids,

On 01/30/2018 02:50 PM, Michael Lawrence wrote: > by() does not always return a list. In Gabe's example, it returns an > integer, thus it is coerced to a list. as.list() means that it should be > a VECSXP, not necessarily with "list" in the class attribute. The documentation is not particularly clear about what as.list() means for list derivatives. IMO clarifications

On Sat, Mar 19, 2016 at 4:29 AM, Herv? Pag?s <hpages at fredhutch.org> wrote: > On 03/19/2016 01:22 AM, Michael Lawrence wrote: > >> >> >> On Sat, Mar 19, 2016 at 12:10 AM, Herv? Pag?s <hpages at fredhutch.org >> <mailto:hpages at fredhutch.org>> wrote: >> >> On 03/18/2016 03:28 PM, Michael Lawrence wrote: >> >> >>

I think that paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",", recycle0=TRUE) should just return an empty string and don't see why it needs to emit a warning or raise an error. To me it does exactly what the user is asking for, which is to change how the 3 arguments are recycled **before** the 'sep'

I understand that this is consistent but it also strikes me as an enormous 'gotcha' of a magnitude that 'we' are trying to avoid/smooth over at this point in user-facing R space. For the record I'm not suggesting it should return something other than "", and in particular I'm not arguing that any call to paste *that does not return an error* with non-NULL

Agreed but I'm not sure we want users accessing documentation with those types of aliases. One option is the method?foo("numeric") syntax. On Thu, Mar 21, 2019 at 9:52 PM Pages, Herve <hpages at fredhutch.org> wrote: > Fine with me as long as eliminating the inconveniences associated with it > can be put on the roadmap. The alias instability and the fact that the user

Gabe, It's the current behavior of paste() that is a major source of bugs: ## Add "rs" prefix to SNP ids and collapse them in a ## comma-separated string. collapse_snp_ids <- function(snp_ids) paste("rs", snp_ids, sep="", collapse=",") snp_groups <- list( group1=c(55, 22, 200), group2=integer(0), group3=c(99,

Hi Herve, Interesting observation with `setClass` but it is for S4. It looks like `data.frame()` is not an S4 class. > isS4(data.frame()) [1] FALSE And in your case this might help: > is(asS4(data.frame()), "list") [1] TRUE Looks like `is` is designed for S4 classes, I am not entirely sure. Best, -Mehmet On 29 November 2017 at 20:46, Herv? Pag?s <hpages at

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Tue, 30 Jan 2018 15:57:42 -0800 writes: > I just meant that the minimal contract for as.list() appears to be that it > returns a VECSXP. To the user, we might say that is.list() will always > return TRUE. Indeed. I also agree with Herv'e that the user level

Fine with me as long as eliminating the inconveniences associated with it can be put on the roadmap. The alias instability and the fact that the user has no way to know if s/he should do ?`foo,numeric-method` or ?`foo,numeric,ANY-method` to find the method has been a long-standing problem. H. On 3/21/19 21:29, Michael Lawrence wrote: If we started over, I'd try to avoid this sort of