On 27/09/2017 6:21 AM, Jens Oehlschlägel wrote:
On 27.09.2017 01:00, Duncan Murdoch wrote:
I think R Core would not be interested in a vote, because you'd be
voting to give them work to do, and that's really rude.
Voting about other people's work is indeed a problem. This is were I
hope money
On 27.09.2017 01:00, Duncan Murdoch wrote:
I think R Core would not be interested in a vote, because you'd be
voting to give them work to do, and that's really rude.
Voting about other people's work is indeed a problem. This is were I
hope money from the R Consortium could help, assuming they
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 willi
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 n
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, di
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 pack
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 fro
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 clean
> 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
>
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] doesn't work for a matrix)
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 bett
On Tue, Sep 26, 2017 at 10:40 AM, Joris Meys wrote:
> 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 j
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 br
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 shows why
> that is
> > -
> 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 def
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, then package
> develop
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 array for column indexing".
On Tue, Sep 26, 2017 at 3:38 PM, Hadley Wickham wrote:
>
> So we should never try and improve upon legacy behaviour? I don't
> understand what you're arguing for here. If a tibble didn't inherit
> from a data frame, it would be useless.
>
> Hadley
>
> --
> http://hadley.nz
>
I didn't say that. I
On Tue, Sep 26, 2017 at 8:51 AM, Pedro J. Aphalo
wrote:
> What I think is troublesome is that data.frame is part of the definition
> of the R language, and the expectation based on R's normal behaviour is
> that testing with is.data.frame() should be enough to ensure that an
> object can be treate
fit here, compared to just calling as.data.frame()
>>>> on it?
>>>>
>>>> Gabor
>>>>
>>>> On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke
>>>> wrote:
>>>>> Since tibbles add their class attributes first, you cou
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, we all agree that the l
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 that they are sticking i
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
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 doesn't change the
>> > fact that a tibble reacts different from a data.
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 tibbles do not
> > inherit correctly from the cla
.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-pkg-devel] tibbles are not data frames
On 2017-09-26 11:56,
ass attributes first, you could use:
> > > >
> > > > tb <- tibble(a = 5)
> > > > inherits(tb, "data.frame", which = TRUE) == 1
> > > >
> > > > if "tb" is a data frame (only), TRUE is returned, for tibble FALSE.
>
E) == 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-package-devel [mailto:r-package-de
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 wrote:
I don't like the dropping of dimensions either. That d
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 t
Cc: R Package Devel
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 wrote:
> Since tibbles add their class attributes first, you could use:
>
> tb <
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 tibble returns TRUE.
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 tibble returns TRUE. So I think that R says - yes, a tibble is a data
frame. What wo
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 _us
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 enough. And I shouldn't have
uot;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-package-devel [mailto:r-package-devel-boun...@r-project.org] Im
> > A
gt; 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
> >
> >
> >
> >
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:
> &g
trö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 wrote:
>>> I don
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
On 2017-09-26 11:56, 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 tibbles do not
inherit correctly from the class data.frame, and it can
On 2017-09-26 11:35, 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 tibbles do not
inherit correctly from the class data.frame, and it can thus be argued
that it's against OOP paradigms to prete
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 tibbles do not
> inherit correctly from the class data.frame, and it can thus be argued that
> it's against OOP
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
data.fram
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 en
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
Joris
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
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 complaints from users of m
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: stefan
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. An
50 matches
Mail list logo
