[Rd] Re: "table" class requirements (was .. Bug in ftable....)
Kurt Hornik
Kurt.Hornik@ci.tuwien.ac.at
Thu, 6 Sep 2001 12:52:57 +0200
>>>>> Martin Maechler writes:
>>>>> "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.
Martin: I view this differently. How can you refer to variables in a
model formula when you do not know their names? [Well I know my ftable
code allows for numbers ... bad design.]
Our implemtation of table is different: we view this as the creator of
class "table" and have methods for it. I do not see this as a source of
imcompatibility: sourcing S+ dumps will not give an object of class
table. If coercing it to one using as.table adds variable names if
needed we'd be safe, I think.
> 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}}.
Need to look up the statement ... cannot seem to find it in my digest?
In any case, I would think that maybe having certain `attributes' is S3
object model thinking ...
-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._