[Rd] Re: "table" class requirements (was .. Bug in ftable....)
Martin Maechler
Martin Maechler <maechler@stat.math.ethz.ch>
Thu, 6 Sep 2001 12:21:29 +0200
>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:
>>>>> Peter Dalgaard BSA writes:
>> "BXC (Bendix Carstensen)" <bxc@novonordisk.com> writes:
>> [tp<- tapply( breaks, list( wool, tension, variant ), mean )]
>>> tp <- as.table( tp )
>>> ftable( tp )
>>>
>>> But here i get:
>>>
>>> > attr( tp, "class" ) <- "table"
>>> > ftable( tp )
>>> Error in cbind(...) : number of rows of matrices must match (see arg 2)
>> Um, I don't think so.... ;-)
>>> # But still they seem to have similar attributes (except for the naming)
>>> attributes( tb )
>>> attributes( tp )
>>>
>>> Is this a bug or a facility of ftable ?
>> It's a bug *somewhere*, not necessarily in ftable. The problem is
>> either that the dimname-names are not added by tapply, that neither
>> as.table or ftable add dummy names, or that write.ftable gags when
>> names are absent. (Or put differently: Are either the "table" or
>> "ftable" objects *required* to have named attributes??).
>> Actually, the fact that tapply doesn't generated named dimnames cannot
>> be considered the cause since
>> (a) as.table should work on any matrix.
>> (b) the second argument to tapply is not a named list in your case
>> One workaround is to add in the names:
>> ft <- ftable(tp)
>> names(attr(ft,"row.vars")) <- c("wool","tension")
>> names(attr(ft,"col.vars")) <- "variant"
>> ft
>> another is to make sure that tapply gets the names right:
>>> tp <- tapply(breaks, list(wool=wool,tension=tension,variant=variant), mean)
>>> ftable(tp)
>> variant 1 2 3 4 5
>> wool tension
>> A L 39.0 40.5 40.0 46.0 70.0
>> M 28.0 29.5 26.5 12.0 18.0
>> H 19.5 22.0 10.0 39.5 24.5
>> B L 31.5 29.0 29.0 27.5 24.5
>> M 39.0 35.0 23.5 29.0 22.5
>> H 17.5 18.0 20.0 22.5 13.0
>> or - lazy variation - abuse the fact that dataframes are lists and do
>> have labeled columns:
>>> tp <- tapply( breaks, data.frame(wool,tension,variant), mean )
>>> ftable(tp)
>> variant 1 2 3 4 5
>> wool tension
>> A L 39.0 40.5 40.0 46.0 70.0
>> M 28.0 29.5 26.5 12.0 18.0
>> H 19.5 22.0 10.0 39.5 24.5
>> B L 31.5 29.0 29.0 27.5 24.5
>> M 39.0 35.0 23.5 29.0 22.5
>> H 17.5 18.0 20.0 22.5 13.0
KH> I think we need to improve as.table.
KH> table() is trying hard to produce variable names, and ftable() [and also
KH> xtabs(), of course] assumes that we have them.
KH> I would suggest enhancing as.table.default to provide dimname names in
KH> addition to adding the "table" class attribute.
I agree with that proposition,
but I disagree with assuming that a "table" class object must have named
dimnames. As long as the other implementations of the S language don't have
these, we will create an unnecessary crevice of incompatibility.
A table could also come along by source()ing an S+-dumped object..
Hence I think ftable(), xtabs() and all *.table() methods *should* work
when the dimnames are not named.
Btw, this is a bit linked to Terry Therneaus strong statements on S-news
yesterday (Subject: Re: [S] dimnames in Sparc Splus 6.0)
about S4 vs S3 classes. I *do* like in many cases to have `polymorphous'
classes which are allowed/but not required to have certain attributes.
Hence I am waiting for replies explaining how this is easily done within the
S4 class system {{hereby admitting that I've not read the green book
carefully enough recently}}.
Martin Maechler <maechler@stat.math.ethz.ch> http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO D10 Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228 <><
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._