similar to: vctrs: a type system for the tidyverse

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

> 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

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

>>> 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): >>> >>>

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

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

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 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,

> > 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 all, I wanted to give you an update on vctrs (<https://vctrs.r-lib.org/>) since I last bought it up here in August. The biggest change is that I now have a much clearer idea of what vctrs is! I?ll summarise that here, and point you to the documentation if you?re interested in learning more. I?m planning on submitting vctrs to CRAN in the near future, but it?s very much a 0.1.0 release

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

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

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

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()),

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

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

Hi Jos?, On Thu, 25 Jun 2020 at 20:05, Jos? Ab?lio Matos <jamatos at fc.up.pt> wrote: > > On Friday, 26 June 2020 00.45.46 WEST Elliott Sales de Andrade wrote: > > Thanks for starting off builds. However, please be careful merging to > > master, as some packages were bumped and have incompatibilities that > > should not be put in stable releases. I will try to come

Though Navigator may mess up any Rtools stuff because it handles the directory trees where packages and dependencies are located, does it not? If so, maybe just reinstall RStudio directly from its website to proceed. Just a guess obviously. Bert On Sat, Mar 16, 2024, 05:09 javad bayat <j.bayat194 at gmail.com> wrote: > Dear Rui; > Many thanks for your reply. I have installed Rtools