head.matrix can return 1000s of columns -- limit to n or add new argument?

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 <maechler at stat.math.ethz.ch>
wrote:

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 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 for
     > those familiar with head(x, 6), it would seem to me.

     > Mike C

Thank you, Gabe, and Michael.
I did like Gabe's proposal already back in July but was
busy and/or vacationing then ...

If you submit this with a patch (that includes changes to both
*.R and *.Rd , including some example) as "wishlist" item to R's
bugzilla, I'm willing/happy to check and commit this to R-devel.

Martin

     > On Sat, Jul 13, 2019 at 8:35 AM Gabriel Becker
     > <gabembecker at gmail.com> wrote:

     >> 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 equivalent
     >> to n = c(6, dim(x)[2], <...>, dim(x)[k]), at least for
     >> the deprecation cycle, if not permanently. It not
     >> recycling would be unexpected based on the behavior of
     >> many R functions but would preserve the current behavior
     >> while granting more fine-grained control to users that
     >> feel they need it.
     >>
     >> A rapidly thrown-together prototype of such a method for
     >> the head of a matrix case is as follows:
     >>
     >> head2 = function(x, n = 6L, ...) { indvecs =
     >> lapply(seq_along(dim(x)), function(i) { if(length(n) >=
     >> i) { ni = n[i] } else { ni = dim(x)[i] } if(ni < 0L) ni =
     >> max(nrow(x) + ni, 0L) else ni = min(ni, dim(x)[i])
     >> seq_len(ni) }) lstargs = c(list(x),indvecs, drop = FALSE)
     >> do.call("[", lstargs) }
     >>
     >>

     >> > mat = matrix(1:100, 10, 10)

     >>

     >> > *head(mat)*

     >>
     >> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
     >>
     >> [1,] 1 11 21 31 41 51 61 71 81 91
     >>
     >> [2,] 2 12 22 32 42 52 62 72 82 92
     >>
     >> [3,] 3 13 23 33 43 53 63 73 83 93
     >>
     >> [4,] 4 14 24 34 44 54 64 74 84 94
     >>
     >> [5,] 5 15 25 35 45 55 65 75 85 95
     >>
     >> [6,] 6 16 26 36 46 56 66 76 86 96
     >>

     >> > *head2(mat)*

     >>
     >> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
     >>
     >> [1,] 1 11 21 31 41 51 61 71 81 91
     >>
     >> [2,] 2 12 22 32 42 52 62 72 82 92
     >>
     >> [3,] 3 13 23 33 43 53 63 73 83 93
     >>
     >> [4,] 4 14 24 34 44 54 64 74 84 94
     >>
     >> [5,] 5 15 25 35 45 55 65 75 85 95
     >>
     >> [6,] 6 16 26 36 46 56 66 76 86 96
     >>

     >> > *head2(mat, c(2, 3))*

     >>
     >> [,1] [,2] [,3]
     >>
     >> [1,] 1 11 21
     >>
     >> [2,] 2 12 22
     >>

     >> > *head2(mat, c(2, -9))*

     >>
     >> [,1]
     >>
     >> [1,] 1
     >>
     >> [2,] 2
     >>
     >>
     >> Now one thing to keep in mind here, is that I think we'd
     >> either a) have to make the non-recycling behavior
     >> permanent, or b) have head treat data.frames and matrices
     >> different with respect to the subsets they grab (which
     >> strikes me as a *Bad Plan *(tm)).
     >>
     >> So I don't think the default behavior would ever be
     >> mat[1:6, 1:6], not because of backwards compatibility,
     >> but because at least in my intuition that is just not
     >> what head on a data.frame should do by default, and I
     >> think the behaviors for the basic rectangular datatypes
     >> should "stick together". I mean, also because of
     >> backwards compatibility, but that could *in theory*
     >> change across a long enough deprecation cycle, but the
     >> conceptually right thing to do with a data.frame probably
     >> won't.
     >>
     >> All of that said, is head(mat, c(6, 6)) really that much
     >> easier to type/better than just mat[1:6, 1:6, drop=FALSE]
     >> (I know this will behave differently if any of the dims
     >> of mat are less than 6, but if so why are you heading it
     >> in the first place ;) )? I don't really have a strong
     >> feeling on the answer to that.
     >>
     >> I'm happy to put a patch for head.matrix,
     >> head.data.frame, tail.matrix and tail.data.frame, plus
     >> documentation, if people on R-core are interested in
     >> this.
     >>
     >> Note, as most here probably know, and as alluded to
     >> above, length(n) > 1 for head or tail currently give an
     >> error, so this would be an extension of the existing
     >> functionality in the mathematical extension sense, where
     >> all existing behavior would remain identical, but the
     >> support/valid parameter space would grow.
     >>
     >> Best, ~G
     >>
     >>
     >> On Fri, Jul 12, 2019 at 4:03 PM Abby Spurdle
     >> <spurdle.a at gmail.com> wrote:
     >>

     >>> > 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 you're trying to achieve.  However,
     >>> I'm not sure this is as simple as you're suggesting.
     >>>
     >>> What if the user wants "head" in rows but "tail" in
     >>> columns.  Or "head" in rows, and both "head" and "tail"
     >>> in columns.  With head and tail alone, there's a
     >>> combinatorial explosion.
     >>>
     >>> Also, when using tail on an unnamed matrix, it may be
     >>> desirable to name rows and columns.
     >>>
     >>> And all of this assumes standard matrix objects.  Add in
     >>> a matrix subclasses and related objects, and things get
     >>> more complex still.
     >>>
     >>> As I suggested in a another thread, a few days ago, I'm
     >>> planning to write an R package for matrices and
     >>> matrix-like objects (possibly extending the Matrix
     >>> package), with an initial emphasis on subsetting,
     >>> printing and formatting.  So, I'm interested to hear
     >>> more suggestions on this topic.
     >>>
     >>> [[alternative HTML version deleted]]
     >>>
     >>> ______________________________________________
     >>> R-devel at r-project.org mailing list
     >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=sOZlR-nzy_f_Sje6VGA6IXYQM01BO39OQ2zqA8mtaGI&s=VyNGYbk1jJJqirYBwnhKX60dCp31ArtS62RmXKn86O4&e=
     >>>

     >>

     >   [[alternative HTML version deleted]]

     > ______________________________________________
     > R-devel at r-project.org mailing list
     > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=sOZlR-nzy_f_Sje6VGA6IXYQM01BO39OQ2zqA8mtaGI&s=VyNGYbk1jJJqirYBwnhKX60dCp31ArtS62RmXKn86O4&e=

	[[alternative HTML version deleted]]