[Rd] Why is there no c.factor?

[William Dunlap]

> -----Original Message-----
> From: r-devel-bounces at r-project.org 
> [mailto:r-devel-bounces at r-project.org] On Behalf Of Peter Dalgaard
> Sent: Friday, February 05, 2010 7:41 AM
> To: Hadley Wickham
> Cc: John Fox; r-devel at r-project.org; Thomas Lumley
> Subject: Re: [Rd] Why is there no c.factor?
> 
> Hadley Wickham wrote:
> > On Thu, Feb 4, 2010 at 12:03 PM, Hadley Wickham 
> <hadley at rice.edu> wrote:
> >>> I'd propose the following: If the sets of levels of all 
> arguments are the
> >>> same, then c.factor() would return a factor with the 
> common set of levels;
> >>> if the sets of levels differ, then, as Hadley suggests, 
> the level-set of the
> >>> result would be the union of sets of levels of the 
> arguments, but a warning
> >>> would be issued.
> >> I like this compromise (as long as there was an argument 
> to suppress
> >> the warning)
> > 
> > If I provided code to do this, along with the warnings for ordered
> > factors and using the optimisation suggested by Matthew, is 
> there any
> > member of R core would be interested in sponsoring it?
> > 
> > Hadley
> > 
> 
> Messing with c() is a bit unattractive (I'm not too happy 
> with the other
> c methods either; normally c() strips attributes and reduces 
> to the base
> class, and those obviously do not), but a more general 
> concat() function
> has been suggested a number of times. With a suitable range 
> of methods,
> this could also be used to reimplement rbind.data.frame (which,
> incidentally, already contains a method for concatenating 
> factors, with
> several ugly warts!)

Yes, c() should have been put on the deprecated list a couple
of decades ago, since people expect it to do too many
incompatible things.  And factor should have been a virtual
class, with subclasses "FixedLevels" (e.g., Sex) or "AdHocLevels"
(e.g., FamilyName), so c() and [()<- could do the appropriate
thing in either case.

Back to reality, S+ has a concat(...) function, whose comments say
	# This function works like c() except that names of arguments are
	# ignored.  That is, it concatenates its arguments into a single
	# S vector object, without considering the names of the arguments, 
	# in the order that the arguments are given.
	#
	# To make this function work for new classes, it is only necessary
	# to make methods for the concat.two function, which concatenates
	# two vectors; recursion will take care of the rest.
concat() is not generic but it repeatedly calls concat.two(x,y), an
SV4-generic that dispatches on the classes of x and y.  Thus you
can easily predict the class of concat(x,y,z), although it may not
be the same as the class of concat(z,y,x), given suitably bizarre
methods for concat.two().

concat() doesn't get a lot of use but I think the idea is sound.
Perhaps that model would work well for a concatenation function in R.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com 

> 
> -- 
>    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
>   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
>  (*) \(*) -- University of Copenhagen   Denmark      Ph:  
> (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)              FAX: 
> (+45) 35327907
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>