From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Sep  6 11:21:29 2001
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 6 Sep 2001 12:21:29 +0200
Subject: [Rd] Re: "table" class requirements (was .. Bug in ftable....)
In-Reply-To: <15255.14462.313764.384032@mithrandir.hornik.net>
References: <D5A7D734C9C5D211B9E30008C78923020E95AFBB@exdkba03.novo.dk>
 <x2g0a2kmo4.fsf@blueberry.kubism.ku.dk>
 <15255.14462.313764.384032@mithrandir.hornik.net>
Message-ID: <15255.20009.696505.653542@gargle.gargle.HOWL>

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


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