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@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: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
