Re: [R-pkg-devel] tibbles are not data frames

On 26.09.2017 23:08, Hadley Wickham wrote: I'm not sure that democracy works for programming language design. Agree. The obstacle I hope to overcome by voting is not missing agreement on the fact of inconsistent design, the obstacle is the question whether a majority of contributers is

Re: [R-pkg-devel] tibbles are not data frames

I suppose that it is far too late to offer such a suggestion, but it seems to me that the problem is in some measure the mechanism of inheritance. First, the tibble (although the name is incomprehensible, why not something like "data.blob") is superior to the bog standard R data.frame. This may

Re: [R-pkg-devel] tibbles are not data frames

Duncan's observation is correct. The background work to the standards I worked on was a big effort, and the content was a lot smaller than R, though possibly similar in scope to dealing with the current question. The "voting" was also very late in the process, after the proposals were developed,

Re: [R-pkg-devel] tibbles are not data frames

On 26/09/2017 4:52 PM, Jens Oehlschlägel wrote: On 26.09.2017 15:37, Hadley Wickham wrote: I decided to make [.tibble type-stable (i.e. always return a data frame) because this behaviour causes substantial problems in real data analysis code. I did it understanding that it would cause some

Re: [R-pkg-devel] tibbles are not data frames

On 26 September 2017 at 22:52, Jens Oehlschlägel wrote: | also the Rcppverse Not really, in the context of this thread. Rcpp does not impose or suggest a particular way of doing things at the R level. Rcpp, really, is mostly about making it a little easier to interface with C/C++ level code

Re: [R-pkg-devel] tibbles are not data frames

Having been around a while and part of several programming language and other standards (see ISO 6373:1984 and IEEE 754-1985), I prefer some democracy at the level of getting a standard. Though perhaps at the design level I can agree with Hadley. However, we're now at the stage of needing to

Re: [R-pkg-devel] tibbles are not data frames

> If that is right -- and I tend to believe it is right -- this change had > better been done in R core and not on package level. I think the root of > this evil is design inconsistencies of the language together with the lack > of removing these inconsistencies. The longer we hesitated, the more

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 12:15 PM, Patrick Perry wrote: > Pro ignoring x[,1,drop=TRUE]: > (1) it forces users to write consistent code for extracting a vector from a > data frame > > Con: > (1) functions that accept both matrices and data frames might break > (x[[j]][i]

Re: [R-pkg-devel] tibbles are not data frames

On 26.09.2017 15:37, Hadley Wickham wrote: I decided to make [.tibble type-stable (i.e. always return a data frame) because this behaviour causes substantial problems in real data analysis code. I did it understanding that it would cause some package developers frustration, but I think it's

Re: [R-pkg-devel] tibbles are not data frames

Pro ignoring x[,1,drop=TRUE]: (1) it forces users to write consistent code for extracting a vector from a data frame Con: (1) functions that accept both matrices and data frames might break (x[[j]][i] doesn't work for a matrix) (2) functions that use the access pattern x[i,j,drop = TRUE] will

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 5:33 PM, Hadley Wickham wrote: > > I for one am happy this discussion pops up, because it's a piece of > > information I give to my students as well: convert to a data.frame when > you > > start your analysis just to play safe. And this discussion

Re: [R-pkg-devel] tibbles are not data frames

> I for one am happy this discussion pops up, because it's a piece of > information I give to my students as well: convert to a data.frame when you > start your analysis just to play safe. And this discussion shows why that is > -for the time being!- a good advice. The moment tibbles become the

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 9:22 AM, Patrick Perry wrote: > Would it be possible to change tibbles so that > > x[,1,drop=TRUE] > > returns a vector, not a data frame? I certainly find it surprising that > tibbles ignore > the drop argument. If tibbles respeced the drop argument,

Re: [R-pkg-devel] tibbles are not data frames

On 2017-09-26 15:37, Hadley Wickham wrote: On Tue, Sep 26, 2017 at 2:30 AM, Göran Broström wrote: I am beginning to get complaints from users of my CRAN packages (especially 'eha') to the effect that they get error messages like "Error: Unsupported use of matrix or

Re: [R-pkg-devel] tibbles are not data frames

;>> What is the benefit here, compared to just calling as.data.frame() >>>> on it? >>>> >>>> Gabor >>>> >>>> On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke <d.luede...@uke.de> >>>> wrote:

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 8:35 AM, Joris Meys wrote: > Where its parent class _sometimes_ returns an atomic vector and >> >> _sometimes_ returns a data frame. > > Indeed. And a tibble doesn't, so there's a conflict. Nobody said data.frame > works better than tibble. Actually,

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 2:30 AM, Göran Broström wrote: > I am beginning to get complaints from users of my CRAN packages (especially > 'eha') to the effect that they get error messages like "Error: Unsupported > use of matrix or array for column indexing". > > It turns out

Re: [R-pkg-devel] tibbles are not data frames

Where its parent class _sometimes_ returns an atomic vector and > _sometimes_ returns a data frame. > > Hadley > Indeed. And a tibble doesn't, so there's a conflict. Nobody said data.frame works better than tibble. Actually, we all agree that the legacy behaviour sucks. But it exists, and causes

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 8:28 AM, Jeroen Ooms wrote: > On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi wrote: >> >> On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys wrote: >> > I don't like the dropping of dimensions either. That

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi wrote: > > On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys wrote: > > I don't like the dropping of dimensions either. That doesn't change the > > fact that a tibble reacts different from a data.frame. So

Re: [R-pkg-devel] tibbles are not data frames

r tibble FALSE. You could then coerce to data frame: as.data.frame(tb) -Ursprüngliche Nachricht- Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im Auftrag von Göran Broström Gesendet: Dienstag, 26. September 2017 12:09 An: r-package-devel@r-project.org Betreff: Re: [R

Re: [R-pkg-devel] tibbles are not data frames

> > > wrote: > > > > Since tibbles add their class attributes first, you could use: > > > > > > > > tb <- tibble(a = 5) > > > > inherits(tb, "data.frame", which = TRUE) == 1 > > > > > > > > i

Re: [R-pkg-devel] tibbles are not data frames

iche Nachricht- >> > Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im >> > Auftrag von Göran Broström >> > Gesendet: Dienstag, 26. September 2017 12:09 >> > An: r-package-devel@r-project.org >> > Betreff: Re: [R-pkg-devel] tibb

Re: [R-pkg-devel] tibbles are not data frames

Devel <r-package-devel@r-project.org> Betreff: Re: [R-pkg-devel] tibbles are not data frames What is the benefit here, compared to just calling as.data.frame() on it? Gabor On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke <d.luede...@uke.de> wrote: Since tibbles add their class att

Re: [R-pkg-devel] tibbles are not data frames

Hi, But the point is that inherits(x, "data.frame", TRUE) == 1 will not distinguish between tibbles and other classes derived from data.frame that do respect the original syntax. You cannot/want in most cases block the use of every class derived from data.frame. One would need to use a test

Re: [R-pkg-devel] tibbles are not data frames

uke.de> Cc: R Package Devel <r-package-devel@r-project.org> Betreff: Re: [R-pkg-devel] tibbles are not data frames What is the benefit here, compared to just calling as.data.frame() on it? Gabor On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke <d.luede...@uke.de> wrote: > Since tib

Re: [R-pkg-devel] tibbles are not data frames

2017-09-26 13:41 GMT+02:00 Holger Hoefling : > Hi Thierry, > > You write: > > "If a package requires a data.frame, then it is up to the _user_ to > provide a data.frame (and a tibble is not a data.frame). " > > Actually, as pointed out before, calling > > is.data.frame > > on a

Re: [R-pkg-devel] tibbles are not data frames

Dear all, IMHO the problem is being look at from the wrong perspective. The tibble doesn't change the data.frame, it uses all methods from data.frame which it doesn't implement itself. Hence it behaves like at data.frame to some extent. If a package requires a data.frame, then it is up to the

Re: [R-pkg-devel] tibbles are not data frames

On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi wrote: > > I have yet to see an OOP system in which a subclass cannot override the > methods > of its superclass. Not only is this in line with OOP paradigms, it is > actually one of > the essential OOP features. > Fair

Re: [R-pkg-devel] tibbles are not data frames

;data.frame", which = TRUE) == 1 > > > > > > if "tb" is a data frame (only), TRUE is returned, for tibble FALSE. You > > could then coerce to data frame: as.data.frame(tb) > > > > > > -Ursprüngliche Nachricht- > > > Von: R-p

Re: [R-pkg-devel] tibbles are not data frames

; > > -Ursprüngliche Nachricht- > > Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im > Auftrag von Göran Broström > > Gesendet: Dienstag, 26. September 2017 12:09 > > An: r-package-devel@r-project.org > > Betreff: Re: [R-pkg-devel] tibbles are

Re: [R-pkg-devel] tibbles are not data frames

n: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im > Auftrag von Göran Broström > > Gesendet: Dienstag, 26. September 2017 12:09 > > An: r-package-devel@r-project.org > > Betreff: Re: [R-pkg-devel] tibbles are not data frames > > > > > > > >

Re: [R-pkg-devel] tibbles are not data frames

] Im > Auftrag von Göran Broström > Gesendet: Dienstag, 26. September 2017 12:09 > An: r-package-devel@r-project.org > Betreff: Re: [R-pkg-devel] tibbles are not data frames > > > > On 2017-09-26 11:56, Gábor Csárdi wrote: >> On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys <

Re: [R-pkg-devel] tibbles are not data frames

e Nachricht- Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im Auftrag von Göran Broström Gesendet: Dienstag, 26. September 2017 12:09 An: r-package-devel@r-project.org Betreff: Re: [R-pkg-devel] tibbles are not data frames On 2017-09-26 11:56, Gábor Csárdi wrote: > On

Re: [R-pkg-devel] tibbles are not data frames

I don't like the dropping of dimensions either. That doesn't change the fact that a tibble reacts different from a data.frame. So tibbles do not inherit correctly from the class data.frame, and it can thus be argued that it's against OOP paradigms to pretend tibbles inherit from the class

Re: [R-pkg-devel] tibbles are not data frames

Thanks for the examples. Personally, I have been struck out multiple times by data frames dropping dimensions, so I have a distaste for this dropping behaviour. Personally, I prefer data frame *not* to drop dimensions. They are not arrays, where slicing drops a dimension makes sense because all

Re: [R-pkg-devel] tibbles are not data frames

Here's one difference: atib <- tibble(a = 1:5, b = letters[5:1]) atib[3,"a"] as.data.frame(atib)[3,"a"] The second line returns a tibble (no dropping dimensions), the third line does (dropping dimensions). Huge difference if you use [ , aColumn] to select a vector from a data frame. Cheers

Re: [R-pkg-devel] tibbles are not data frames

Hej Stefan, On 2017-09-26 10:57, Stefan McKinnon Høj-Edwards wrote: Hi Göran, Could you please elaborate on which kind of subsetting that Hadley dislikes? I am yet to encounter operations on data frames that are not possible on tribbles. For instance, if 'dat' is a data frame, dat[1:3, 5]

Re: [R-pkg-devel] tibbles are not data frames

I could not agree more with Göran and we had to change code in our packages because if this too. I also see students often facing bugs because of it. Again, with all the respect I have for Hadley. On 26 Sep 2017 9:32 a.m., "Göran Broström" wrote: I am beginning to get

Re: [R-pkg-devel] tibbles are not data frames

Hi Göran, Could you please elaborate on which kind of subsetting that Hadley dislikes? I am yet to encounter operations on data frames that are not possible on tribbles. Kindly, Stefan McKinnon Hoj-Edwards Stefan McKinnon Høj-Edwards ph.d. Genetics +44 (0)776 231 2464 +45 2888 6598 Skype:

[R-pkg-devel] tibbles are not data frames

I am beginning to get complaints from users of my CRAN packages (especially 'eha') to the effect that they get error messages like "Error: Unsupported use of matrix or array for column indexing". It turns out that they are sticking in tibbles into functions that expect data frames as input.