> Gabriel Becker
> on Sat, 2 Nov 2019 12:40:16 -0700 writes:
[]
In the mean time, Gabe had worked quite a bit and provided a
patch proposal at R's bugzilla, PR#17652 ,
i.e., here
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17652
A few days ag
As I hit send I realized I did know of one, which is table objects. So
while we're discussing it we can talk about both generally and specifically
what head.table and tail.table should do. Looks like tail.table is already
special -cased to hit the matrix method if it is 2d, so the natural
extension
Thanks Martin and Peter,
I agree that we can be careful and narrow and still see a nice improvement
in behavior. While Herve's point is valid and I understand his frustration,
I think staying within the matrix vs c(matrix, array) space is the right
scope for this work in terms of fiddling with in
> peter dalgaard
> on Thu, 31 Oct 2019 23:04:29 +0100 writes:
> Hmm, the problem I see here is that these implied classes are all
inherently one-off. We also have
>> inherits(matrix(1,1,1),"numeric")
> [1] FALSE
>> is.numeric(matrix(1,1,1))
> [1] TRUE
>> inhe
> Pages, Herve
> on Thu, 31 Oct 2019 21:02:07 + writes:
> On 10/30/19 04:29, Martin Maechler wrote:
>>> Gabriel Becker
>>> on Tue, 29 Oct 2019 12:43:15 -0700 writes:
>>
>> > Hi all,
>> > So I've started working on this and I ran into something that
Hmm, the problem I see here is that these implied classes are all inherently
one-off. We also have
> inherits(matrix(1,1,1),"numeric")
[1] FALSE
> is.numeric(matrix(1,1,1))
[1] TRUE
> inherits(1L,"numeric")
[1] FALSE
> is.numeric(1L)
[1] TRUE
and if we start fixing one, we might need to fix all
On Fri, Nov 1, 2019 at 10:02 AM Pages, Herve wrote:
> That would be awesome! More generally I wonder how feasible it would be
> to fix all these inheritance quirks where inherits(x, "something"),
> is(x, "something"), and is.something(x) disagree. They've been such a
> nuisance for so many years..
On 10/30/19 04:29, Martin Maechler wrote:
>> Gabriel Becker
>> on Tue, 29 Oct 2019 12:43:15 -0700 writes:
>
> > Hi all,
> > So I've started working on this and I ran into something that I didn't
> > know, namely that for x a multi-dimensional (2+) array, head(x) and
>
Hi Martin,
On Wed, Oct 30, 2019 at 4:30 AM Martin Maechler
wrote:
> > Gabriel Becker
> > on Tue, 29 Oct 2019 12:43:15 -0700 writes:
>
> > Hi all,
> > So I've started working on this and I ran into something that I
> didn't
> > know, namely that for x a multi-dimensional
> Gabriel Becker
> on Tue, 29 Oct 2019 12:43:15 -0700 writes:
> Hi all,
> So I've started working on this and I ran into something that I didn't
> know, namely that for x a multi-dimensional (2+) array, head(x) and
tail(x)
> ignore dimension completely, treat x as an
Gabriel,
My view is rather radical.
- head/tail should return object having same number of dimensions
- data.frame should be a special case
- matrix should be handled as 2D array
P.S. idea of accepting `n` argument as a vector of corresponding
dimensions is a brilliant one
On Wed, Oct 30, 2019 a
Hi all,
So I've started working on this and I ran into something that I didn't
know, namely that for x a multi-dimensional (2+) array, head(x) and tail(x)
ignore dimension completely, treat x as an atomic vector, and return an
(unclassed) atomic vector:
> x = array(100, c(4, 5, 5))
> dim(x)
[1]
Hi Martin et al.
Sorry for not getting back onto this sooner. I've been pretty well buried
under travel plus being sick for a bit, but I will be happy to roll up a
patch for this, including documentation and put it into a wishlist item.
I'll aim to do that at some point next week.
Thanks @Martin
> Fox, John
> on Tue, 17 Sep 2019 12:32:13 + writes:
> Dear Herve,
> Sorry, I should have said "matrices" rather than "data frames" -- brief()
has methods for both.
> Best,
> John
> -
> John Fox, Professor Emeritus
> McMas
Dear Herve,
Sorry, I should have said "matrices" rather than "data frames" -- brief() has
methods for both.
Best,
John
-
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
Web: http::/socserv.mcmaster.ca/jfox
> On Sep 17, 2019, at
Dear Herve,
The brief() generic function in the car package does something very similar to
that for data frames (and has methods for other classes of objects as well).
Best,
John
-
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
Hi,
Alternatively, how about a new glance() generic that would do something
like this:
> library(DelayedArray)
> glance <- DelayedArray:::show_compact_array
> M <- matrix(rnorm(1e6), nrow = 1000L, ncol = 2000L)
> glance(M)
<1000 x 2000> matrix object of type "double":
[,1]
Awesome. Gabe, since you already have a workshopped version, would you like
to proceed? Feel free to ping me to review the patch once it's posted.
On Mon, Sep 16, 2019 at 3:26 PM Martin Maechler
wrote:
> > Michael Chirico
> > on Sun, 15 Sep 2019 20:52:34 +0800 writes:
>
> > Final
> Michael Chirico
> on Sun, 15 Sep 2019 20:52:34 +0800 writes:
> Finally read in detail your response Gabe. Looks great,
> and I agree it's quite intuitive, as well as agree against
> non-recycling.
> Once the length(n) == length(dim(x)) behavior is enabled,
> I d
Finally read in detail your response Gabe. Looks great, and I agree it's
quite intuitive, as well as agree against non-recycling.
Once the length(n) == length(dim(x)) behavior is enabled, I don't think
there's any need/desire to have head() do x[1:6,1:6] anymore. head(x, c(6,
6)) is quite clear fo
Hi Michael and Abby,
So one thing that could happen that would be backwards compatible (with the
exception of something that was an error no longer being an error) is head
and tail could take vectors of length (dim(x)) rather than integers of
length for n, with the default being n=6 being equivale
> I assume there are lots of backwards-compatibility issues as well as valid
> use cases for this behavior, so I guess defaulting to M[1:6, 1:6] is out
of
> the question.
Agree.
> Is there any scope for adding a new argument to head.matrix that would
> allow this flexibility?
I agree with what y
22 matches
Mail list logo
