[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