[Rd] Format printing inside a matrix
Jialin Ma
m@r||n- @end|ng |rom gmx@cn
Mon Jul 8 07:10:11 CEST 2019
Hi Hervé,
> Is it? One could argue that a more sensible behavior would be that
> things like `[`(..., drop=FALSE), rbind(), cbind(), etc... preserve
> the class attribute.
>
> Interestingly t() does that
>
> So if it makes sense for t() and reshaping, it's not clear why it
> wouldn't for [, aperm(), cbind(), etc...?
Thanks for the interesting example and I did not test these functions before.
It seems to me that it indeed makes senses to preserve class attributes for
these functions -- if there is no specific reason to drop them.
And it will make it a lot easier extending the behaviors of base list, matrix
and array.
Best regards,
Jialin
On Sunday, July 7, 2019 9:32:29 PM PDT Pages, Herve wrote:
> On 7/7/19 17:41, Jialin Ma wrote:
>
> > Hi Abby,
> >
> > Thanks a lot for your paraphrasing and your suggestion!
> >
> > The problem of wrapping the list into a S3/S4 object, i.e. subclassing
> > array
or matrix, is that one also has to define a bunch of methods for
> > subsetting, joining, etc, in order to make it behave like a list array.
> > The reason is that most R functions for subsetting, joining, etc. do not
> > preserve class attributes of the input, which is possibly by design.
>
>
> Is it? One could argue that a more sensible behavior would be that
> things like `[`(..., drop=FALSE), rbind(), cbind(), etc... preserve
> the class attribute.
>
> Interestingly t() does that:
>
> m <- matrix(1:6, nrow=2)
> class(m) <- "foo"
>
> m
> # [,1] [,2] [,3]
> # [1,] 1 3 5
> # [2,] 2 4 6
> # attr(,"class")
> # [1] "foo"
>
> t(m)
> # [,1] [,2]
> # [1,] 1 2
> # [2,] 3 4
> # [3,] 5 6
> # attr(,"class")
> # [1] "foo"
>
> but not aperm() (which in this case would be expected to be
> equivalent to t()):
>
> aperm(m, 2:1)
> # [,1] [,2]
> # [1,] 1 2
> # [2,] 3 4
> # [3,] 5 6
>
> Reshaping also preserves the class:
>
> dim(m) <- c(6, 1)
> m
> # [,1]
> # [1,] 1
> # [2,] 2
> # [3,] 3
> # [4,] 4
> # [5,] 5
> # [6,] 6
> # attr(,"class")
> # [1] "foo"
>
> So if it makes sense for t() and reshaping, it's not clear why it
> wouldn't for [, aperm(), cbind(), etc...?
>
> H.
>
>
>
> > It is not desirable if a
> > simple matrix subsetting will remove the class attributes of the object.
> >
> > There are also many other common functions that are meant to drop the
> > attributes of the input, e.g. lapply, apply -- they are not generics and
> > it is
not wise to override them.
> >
> > Overall, introducing a new S3/S4 class often brings some extra price in
> > order
to maintain the correct behavior, which is why I tend to avoid
> > them unless it is necessary.
> >
> > Best regards,
> > Jialin
> >
> > On Sunday, July 7, 2019 4:43:59 PM PDT Abby Spurdle wrote:
> >
> >> contains an array of question marks, which
> >> isn't helpful.
> >>
> >>
> >>
> >> Would it be possible for the print method for both matrices and arrays
> >> (conditional on having a list type), call the format method for each
> >> object, possibly creating a character matrix?
> >> Presumably there are other approaches, but the main thing is that the
> >> output is useful and it's easy for R users to control the way objects
> >> (in
> >> matrices and arrays) are printed.
> >>
> >>
> >>
> >>> Or is there any other place that I can override without introducing a
> >>> new
> >>
> >>
> >>
> >> S3 class?
> >>
> >>
> >>
> >> In theory, the simplest approach is to redefine the print method for
> >> matrices.
> >> However, that would be unacceptable in a CRAN package, probably...
> >>
> >>
> >>
> >> So, unless R Core change the print method, you may have to create a
> >> matrix
> >> subclass.
> >
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_
> > listinfo_r-2Ddevel&d=DwIFAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_
> > wJYbW0WYiZvSXAJJKaaPhzWA&m=CFwIFXl8lv7HqmAdD6GKNJ6jlR0VRL1Ek1iGNO_suAk&s=M
> > hiq-DX7GTrcmqUFXKjuATvQy8Zs6op359DAMvOrois&e=
>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpages using fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
More information about the R-devel
mailing list