similar to: An update on the vctrs package

Hadley, Looks interesting and like a fun project from what you said in the email (I don't have time right now to dig deep into the readme) A few thoughts. First off, you are using the word "type" throughout this email; You seem to mean class (judging by your Date and factor examples, and the fact you mention S3 dispatch) as opposed to type in the sense of what is returned by

Hi all, I wanted to share with you an experimental package that I?m currently working on: vctrs, <https://github.com/r-lib/vctrs>. The motivation for vctrs is to think deeply about the output ?type? of functions like `c()`, `ifelse()`, and `rbind()`, with an eye to implementing one strategy throughout the tidyverse (i.e. all the functions listed at

Kia Ora > vec_size(data.frame(x = 1:10)) > #> [1] 10 > vec_size(array(dim = c(10, 4, 1))) > #> [1] 10 I think that "length" (in the R way) or "size" should incorporate the number of columns (or other dimension information). How about: > vec_npoints (x) > vec_nrecords (x) > vec_nobs (x) Depending on whether you want to promote geometry, databases

> I'm now confident that I > can avoid using "type" by itself, and instead always use it in a > compound phrase (like type system) to avoid confusion. That leaves the > `.type` argument to many vctrs functions. I'm considering change it to > .prototype, because what you actually give it is a zero-length vector > of the class you want, i.e. a prototype of the

Hi i need use these 2 librarys? ( vctrs ) and ( ggplot2 ) , and the 2 librarys are installed in my Rstudio? RStudio Version 1.2.5033 ? 2009-2019 RStudio, Inc. "Orange Blossom" (330255dd, 2019-12-04) but i got all times thesse messages....please help-me...thanks lot of > library ( vctrs ) Error: package or namespace load failed for ?vctrs? in loadNamespace(i, c(lib.loc, .libPaths()),

>>> Method dispatch for `vec_c()` is quite simple because associativity and >>> commutativity mean that we can determine the output type only by >>> considering a pair of inputs at a time. To this end, vctrs provides >>> `vec_type2()` which takes two inputs and returns their common type >>> (represented as zero length vector): >>> >>>

On Thu, Aug 9, 2018 at 4:26 PM jan Vitek <vitekj at icloud.com> wrote: > > > I'm now confident that I > > can avoid using "type" by itself, and instead always use it in a > > compound phrase (like type system) to avoid confusion. That leaves the > > `.type` argument to many vctrs functions. I'm considering change it to > > .prototype,

> > I now have a better argument, I think: > > > If you squint your brain a little, I think you can see > > that each set of automatic coercions is about increasing > > resolution. Integers are low resolution versions of > > doubles, and dates are low resolution versions of > > date-times. Logicals are low resolution version of >

Actually, I sent that too quickly, I should have let it stew a bit more. I've changed my mind about the resolution argument I Was trying to make. There is more information, technically speaking, in the factor with empty levels. I'm still not convinced that its the right behavior, personally. It may just be me though, since Martin seems on board. Mostly I'm just very wary of taking away

> > As Gabe mentioned (and you've explained about) the term "type" > > is really confusing here. As you know, the R internals are all > > about SEXPs, TYPEOF(), etc, and that's what the R level > > typeof(.) also returns. As you want to use something slightly > > different, it should be different naming, ideally something not > > existing yet

Hi Hadley, my point actually came from a data analyst point of view. A character variable is something used for extra information, eg the "any other ideas?" field of a questionnaire. A categorical variable is a variable describing categories defined by the researcher. If it is made clear that a factor is the object type needed for a categorical variable, there is no confusion. All my

Hadley, Responses inline. On Wed, Aug 8, 2018 at 7:34 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > >>> Method dispatch for `vec_c()` is quite simple because associativity and > >>> commutativity mean that we can determine the output type only by > >>> considering a pair of inputs at a time. To this end, vctrs provides > >>>

> First off, you are using the word "type" throughout this email; You seem to > mean class (judging by your Date and factor examples, and the fact you > mention S3 dispatch) as opposed to type in the sense of what is returned by > R's typeof() function. I think it would be clearer if you called it class > throughout unless that isn't actually what you mean (in

El mi?., 8 ago. 2018 a las 19:23, Gabe Becker (<becker.gabe at gene.com>) escribi?: > > Actually, I sent that too quickly, I should have let it stew a bit more. > I've changed my mind about the resolution argument I Was trying to make. > There is more information, technically speaking, in the factor with empty > levels. I'm still not convinced that its the right

On Thu, Aug 9, 2018 at 3:57 AM Joris Meys <jorismeys at gmail.com> wrote: > > I sent this to I?aki personally by mistake. Thank you for notifying me. > > On Wed, Aug 8, 2018 at 7:53 PM I?aki ?car <i.ucar86 at gmail.com> wrote: > > > > > For what it's worth, I always thought about factors as fundamentally > > characters, but with restrictions: a

>>>>> Hadley Wickham >>>>> on Wed, 8 Aug 2018 09:34:42 -0500 writes: >>>> Method dispatch for `vec_c()` is quite simple because >>>> associativity and commutativity mean that we can >>>> determine the output type only by considering a pair of >>>> inputs at a time. To this end, vctrs provides

>> So we say that a >> factor `x` has finer resolution than factor `y` if the levels of `y` >> are contained in `x`. So to find the common type of two factors, we >> take the union of the levels of each factor, given a factor that has >> finer resolution than both. > > I'm not so sure. I think a more useful definition of resolution may be > that it is

----- Original Message ----- > On 2 October 2013 12:17, Renato Golin < renato.golin at linaro.org > > wrote: > > > > > On 2 October 2013 10:12, Steven Newbury < steve at snewbury.org.uk > > wrote: > > > > > > How does this make any sense? > > > I have to agree with you that this doesn't make much sense, but there > is

I sent this to I?aki personally by mistake. Thank you for notifying me. On Wed, Aug 8, 2018 at 7:53 PM I?aki ?car <i.ucar86 at gmail.com> wrote: > > For what it's worth, I always thought about factors as fundamentally > characters, but with restrictions: a subspace of all possible strings. > And I'd say that a non-negligible number of R users may think about > them

> I think one could implement hashing on the fly without any > serialization, similarly to how identical works, but I am not aware of > any existing implementation We have one in vctrs but it's not exported: https://github.com/r-lib/vctrs/blob/main/src/hash.c The main use is vectorised hashing: ``` # Non-vectorised vctrs:::obj_hash(1:10) #> [1] 1e 77 ce 48 # Vectorised