[Rd] Re: "table" class requirements (was .. Bug in ftable....)

[Kurt Hornik]

>>>>> 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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._