I've been writing functions for block matrices and more generally, arrays of matrices.
Presumably, the default transpose operation would transpose everything. But there are situations where one might want to transpose the top-level matrix (of submatrices) but not the submatrices, themselves. Or vice versa. On a side note, the help file for base::aperm is entitled "Array Transposition". So, this topic is not quite as simple as it may sound. Interestingly, the aperm generic function *does* have dots. On Fri, Jan 29, 2021 at 3:37 PM Gabriel Becker <gabembec...@gmail.com> wrote: > > Out of my naive curiosity, what arguments are you hoping a method for t() > will take? > > I mean honestly an argument could be made that all S3 generics should take > .... I don't think its an overwhelmingly compelling one, but I d see some > merit to it given what an s3 generic is at its core. > > ~G > > On Thu, Jan 28, 2021 at 5:27 PM Abby Spurdle <spurdl...@gmail.com> wrote: >> >> That's a great suggestion Davis. >> >> While, we're on the topic... >> Could we have a "dots" argument in base::t, the transpose function? >> >> >> On Fri, Jan 29, 2021 at 4:48 AM Davis Vaughan <da...@rstudio.com> wrote: >> > >> > I should also say that I would be willing to attempt a patch for this, if >> > others agree that this would be useful. >> > >> > - Davis >> > >> > On Thu, Jan 28, 2021 at 9:14 AM Davis Vaughan <da...@rstudio.com> wrote: >> > >> > > Hi all, >> > > >> > > I would like to propose adding `...` to the signatures of the following >> > > rounding functions: >> > > >> > > - floor(x) >> > > - ceiling(x) >> > > - round(x, digits = 0) >> > > - And possibly signif(x, digits = 6) >> > > >> > > The purpose would be to allow S3 methods to add additional arguments as >> > > required. >> > > >> > > A few arguments in favor of this change: >> > > >> > > `trunc(x, ...)` already takes dots, which sets a precedent for the others >> > > to do so as well. It is documented in the same help file as the other >> > > rounding functions. >> > > >> > > Internally at the C level, a check is done to ensure that there is >> > > exactly >> > > 1 arg for floor() and ceiling(), and either 1 or 2 args for round(). The >> > > actual names of those arguments are not checked, however, and I believe >> > > this is what allows `round.Date(x, ...)` and `round.POSIXt(x, unit)` to >> > > exist, solely because they have 2 arguments. It seems like this is a bit >> > > of >> > > a hack, since you couldn't create something similar for floor, like >> > > `floor.POSIXt(x, unit)` (not saying this should exist, it is just for >> > > argument's sake), because the 1 argument check would error on this. I >> > > think >> > > adding `...` to the signature of the generics would better support what >> > > is >> > > being done here. >> > > >> > > Additionally, I have a custom date-like S3 class of my own that I would >> > > like to write floor(), ceiling(), and round() methods for, and they would >> > > require passing additional arguments. >> > > >> > > If R core would like to make this change, they could probably tweak >> > > `do_trunc()` to be a bit more general, and use it for floor() and >> > > ceiling(), since it already allows `...`. >> > > >> > > A few references: >> > > >> > > Check for 1 arg in do_math1(), used by floor() and ceiling() >> > > >> > > https://github.com/wch/r-source/blob/fe82da3baf849fcd3cc7dbc31c6abc72b57aa083/src/main/arithmetic.c#L1270 >> > > >> > > Check for 2 args in do_Math2(), used by round() >> > > >> > > https://github.com/wch/r-source/blob/fe82da3baf849fcd3cc7dbc31c6abc72b57aa083/src/main/arithmetic.c#L1655 >> > > >> > > do_trunc() definition that allows `...` >> > > >> > > https://github.com/wch/r-source/blob/fe82da3baf849fcd3cc7dbc31c6abc72b57aa083/src/main/arithmetic.c#L1329-L1340 >> > > >> > > - Davis >> > > >> > >> > [[alternative HTML version deleted]] >> > >> > ______________________________________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
