Maximilian Paulisch
Maximilian Paulisch
Closes #1408. For example this is relevant for `coalesce()` like uses, e.g. `vec_assign(x, is.na(x), 1L)`. I only added this optimisation for `vec_assign_opts()` and not for other functions in `slice-assign.h` e.g....
Useful e.g. in `vec_slice(x, !is.na(x))` ``` r library(rlang) library(vctrs) n expression min median `itr/sec` mem_alloc `gc/sec` #> #> 1 false_n 29.6ms 30.6ms 28.9 76.3MB 30.3 # After #> # A...
I guess it's not a big issue but I don't know whether it makes sense that `vec_ptype()` and `vec_ptype_common()` produce different results: ``` r library(vctrs) vec_ptype(NA) #> [0] vec_ptype2(NA, NA)...
`vec_is()` always returns `FALSE`. Is this intended behaviour? ``` r library(vctrs) x [1] FALSE ``` Created on 2022-06-20 by the [reprex package](https://reprex.tidyverse.org) (v2.0.1) There is an unexported function `is_unspecified()`. Probably...
I was wondering why the new implementation of `unnest_wider()` is so slow and memory hungry for tibble columns. It turned out to be an issue with `vec_unchop()`: ``` r library(vctrs)...
When binding many 1 row tibbles `vec_c()` is 20% to 40% faster than `vec_rbind()`. I would have expected `vec_rbind()` to be faster as this seems to be the main purpose...
`vec_assign()` needs less memory and is way faster for lists than `vec_slice()` ``` r library(rlang) library(vctrs) x_org
Similarly to #1400 I think it would make sense to have a fast path for `vec_assign(x, integer())` The motivation is also similar: e.g. when using `vec_assign()` in a `coalesce()` like...
I'm not sure how often this is actually relevant in real life but it might be worth to have a "fast path" in `vec_slice()` when the `i` is a logical...
It only works if all levels are specified ``` r library(vctrs) str(vec_c("red", "blue", .ptype = factor())) #> Factor w/ 0 levels: 1 1 str(vec_c(factor("red"), factor("blue"), .ptype = factor())) #> Factor...