search for: vctrs

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 <https://github.com/r-lib/vctrs#tid...

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

...hat while the components of the system are classes > (and indeed it's implemented using S3), the coercion/casting > relationship do not strictly follow the subclass/superclass > relationships. I've taken another pass through (the first part of) the readme (https://github.com/r-lib/vctrs#vctrs), and 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...

...sn't actually what you mean (in which case I would have other questions...) More thoughts inline. On Mon, Aug 6, 2018 at 9:21 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > 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 > <https://github...

...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, because what you actually give it is a zero-length vector > > of the class you want, i.e. a prototype of the desired output. What do > > you think of prototype as a name? > > > The term ?type system? in computer...

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

> 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 desired output. What do > you think of prototype as a name? The term ?type system? in computer science is used in very diff...

...ned by superclass/subclass relationships. > More thoughts inline. > > On Mon, Aug 6, 2018 at 9:21 AM, Hadley Wickham <h.wickham at gmail.com> wrote: >> >> 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 >> &l...

> 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 vctrs:::vec_hash(1L) #> [1] 70 a2 85 ef vctrs:::vec_hash(1:2) #> [1] 70 a2 85 ef bf 3c 2c cf #...

>>> 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): >>> >>> str(vec_type2(integer(), double())) >>> #> num(0) >>> >>> str(vec_type2(factor("a&quot...

...8 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 >>>> `vec_type2()` which takes two inputs and returns their >>>> common type (represented as zero length vector): >>>> >>>> str(vec_type2(integer(), double())) #> num(0) >>>> >>>> str(vec_t...

...iner resolution than > > both. Finally, you can think of a character vector as a > > factor with every possible level, so factors and character > > vectors are coercible. > > > (extracted from the in-progress vignette explaining how to > > extend vctrs to work with your own vctrs, now that vctrs > > has been rewritten to use double dispatch) > > I like this argumentation, and find it very nice indeed! > It confirms my own gut feeling which had lead me to agreeing > with you, Hadley, that taking the union of all factor levels...

...> > >>>> 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): > >>>> > >>>> str(vec_type2(integer(), double())) #> num(0) > >>>> >...

...lm 0.9.2 0.9.1 digest 0.6.25 0.6.22 fs 1.4.1 1.3.1 - was missing dependencies before, I think? gargle 0.5.0 0.4.0 - was missing latest testthat; should be fine to update glue 1.4.1 1.3.2 - requires new vctrs; do not bump haven 2.3.0 2.2.0 - requires new vctrs; do not bump httpuv 1.5.4 1.5.3.1 later 1.1.0.1 1.0.0 lubridate 1.7.8 1.7.4 - should be okay to build 1.7.8, but not 1.7.9, as it needs new vctrs matrixStats 0.56.0 0.55.0...

...tion to something that's essentially a misunderstanding. It's something that's only solved by explaining it correctly imho. Cheers Joris On Thu, Aug 9, 2018 at 2:36 PM Hadley Wickham <h.wickham at gmail.com> wrote: > > I 100% agree with you, and is this the behaviour that vctrs used to > have and dplyr currently has (at least in bind_rows()). But > pragmatically, my experience with dplyr is that people find this > behaviour confusing and unhelpful. And when I played the full > expression of this behaviour in vctrs, I found that it forced me to > think about...

..., 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 > >>> `vec_type2()` which takes two inputs and returns their common type > >>> (represented as zero length vector): > >>> > >>> str(vec_type2(integer(), double())) > >>> #> num(0) > >>> > >>>...

...u merge > that data. > > So imho the combination of two factors with different levels (or even > levels in a different order) should give an error. Which R currently > doesn't throw, so I get there's room for improvement. I 100% agree with you, and is this the behaviour that vctrs used to have and dplyr currently has (at least in bind_rows()). But pragmatically, my experience with dplyr is that people find this behaviour confusing and unhelpful. And when I played the full expression of this behaviour in vctrs, I found that it forced me to think about the levels of factors mo...

...>>>> 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): > > >>>> > > >>>> str(vec_type2(integer(), double())) #> num(0) > >...

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

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