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

Move tbl_cube to another package #4429

Closed
romainfrancois opened this issue Jun 21, 2019 · 5 comments
Closed

Move tbl_cube to another package #4429

romainfrancois opened this issue Jun 21, 2019 · 5 comments
Labels
wip

Comments

@romainfrancois
Copy link
Member

romainfrancois commented Jun 21, 2019

This is not really part of the core dplyr experience, so the cube functionality can be moved to another package with its own release cycle, etc ...

@romainfrancois romainfrancois added the tidy-dev-day 🤓 label Jun 21, 2019
@juangomezduaso
Copy link

juangomezduaso commented Jun 22, 2019

In sight of the advanced state of the rray package and the functionality it already has, I wonder if it wouldn't be much better to let it take care of the use cases where array is the natural data structure to use, and dedicate the efforts to ease the transitio between both "worlds".
I brainstormed the same idea from the other side in this post

@krlmlr
Copy link
Member

krlmlr commented Jul 10, 2019

@juangomezduaso: "this post": did you mean to add a link?

CC @DavisVaughan.

@DavisVaughan
Copy link
Member

DavisVaughan commented Jul 10, 2019

I still think the idea of a 3D data structure of mixed types could be useful in some fields, so I don't think rray would ever replace the tbl_cube completely. I do agree that it would probably be better suited in another package though

@juangomezduaso
Copy link

juangomezduaso commented Jul 10, 2019

Oh sorry! Yes,In wanted to link to: r-lib/rray#231 (comment)
tblcube, as it is now, seems to me like a somehow constraining alternative to the use of independent rray arrays. I understand that it was designed to folow the conventions and philosophy of dplyr, and so it was limited to be just a different backend to implement the same functionality (verbs) of dplyr in situations where the exhaustivity of the crossing of clasifications makes it more compact and performant to use arrays rather than the relational usual alternative in dplyr backends.
But I think that in these scenarios broadcasting arrays are a better data model. Specially when there are lots of calculations mixing variables at different levels of aggregation, dplyr requires many joinings that broadcasting arrays just dont need.
Perhaps a new tblcube based on rray arrays would reach agood compromise, but I think that tying the measures in a dataframe style is unnecesarily constraining the posibilities. Arrays can go beyond the sql alternative role and be kind of a a worksheet substitute.
So I see a better path for the tidyverse to take advantage of the two excelent packages it now has, letting each one take care of what it does best and easing the transition between both data models (with ideas lke the one commented in the linked issue)

hadley added a commit that referenced this issue Dec 12, 2019
@hadley hadley added wip and removed tidy-dev-day 🤓 labels Dec 12, 2019
@hadley hadley closed this as completed in d9b81e4 Dec 13, 2019
@lock
Copy link

lock bot commented Jun 24, 2020

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/

@lock lock bot locked and limited conversation to collaborators Jun 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
wip
Projects
None yet
Development

No branches or pull requests

5 participants