Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map functions with vctrs semantics #1941

Closed
tzakharko opened this issue Jun 17, 2024 · 3 comments
Closed

Map functions with vctrs semantics #1941

tzakharko opened this issue Jun 17, 2024 · 3 comments

Comments

@tzakharko
Copy link

tzakharko commented Jun 17, 2024

It appreas that the ecosystem is still lacking a map primitive with vctrs-compatible semantics. I recall there was an effort to implement mapping as part of vctrs (e.g. #1227), which was abandoned in favour of map_vec() in purrr. However, purrr does not offer vctrs-compatible semantics, in particular it has inconsistent treatment of data frames (see for example tidyverse/purrr#838).

I believe that the vctrs approach to treating tables as row-iterable vectors is very powerful and allows the intuitive composition of complex data. This semantics also powers many advanced features within dplyr. Are there plans to bring this to list iteration?

@DavisVaughan
Copy link
Member

DavisVaughan commented Jun 17, 2024

treating tables as row-iterable vectors

slider::slide() does exactly that and is likely as close as we will get
https://slider.r-lib.org/articles/rowwise.html

It uses vctrs iteration under the hood and is mostly implemented in C to make it as fast as possible, but it still does have to callback to R to call the .f function on every row

@tzakharko
Copy link
Author

Thanks, @DavisVaughan! I was not aware that slider is positioned as a general solution to this problem (my hope that there were plans for this in vctrs or purrr). I suppose that's another package to add to the dependency list :)

@DavisVaughan
Copy link
Member

DavisVaughan commented Jun 17, 2024

slider is well maintained and as lightweight dependency wise as purrr, so it should work pretty well for your use cases, I think!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants