From p.dalgaard@biostat.ku.dk  Thu Aug  5 18:04:16 1999
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 05 Aug 1999 19:04:16 +0200
Subject: cbind is not generic as claimed, omits labels where S has them (PR#240)
In-Reply-To: ripley@stats.ox.ac.uk's message of "Thu, 5 Aug 1999 18:17:14 +0200 (MET DST)"
References: <199908051617.SAA02592@pubhealth.ku.dk>
Message-ID: <x2emhignvz.fsf@blueberry.kubism.ku.dk>

ripley@stats.ox.ac.uk writes:

> On 5 Aug 1999, Peter Dalgaard BSA wrote:
> 
> > (1) The docs are clearly wrong (or perhaps rather, wishful thinking)
> 
> Sorry, but always the docs are right and the implementation wrong.
> That's an axiom of professional computer programming (so I am told
> by several ex-professional computer programmers.)

Hmm. I think there are counterexamples...

> 
> > (2) Cbind should be generic as in Splus
> > 
> > (3) For the labels, one needs essentially to implement deparse.level
> >     or face the horrors of
> >     eval(substitute(cbind(a,b,deparse.level=2),list(a=rnorm(10),b=rnorm(10))))
> 
> Really? Or try a bit less hard?  Getting the common cases right is not
> too hard -- ts.union etc seem normally to be about right, and they have
> simple code.

I don't think it's hard to implement deparse.level. The main
difficulty is figuring out who does the deparsing. The generic, the
default, or the specific method? 

> > (4) The dataframe special casing seems to be an evasion. The sticky
> >     bit is that one needs to dispatch on *any* argument. For Splus (3.4)
> >     compatibility, one has to check each argument for its class
> >     method, and if all arguments agree - in the sense that all the
> >     arguments that have class methods must have the same one, dispatch
> >     to that method. If they disagree, print error message and try
> >     default method. 
> > 
> >     Whoever wrote the code seems to have decided that things would be
> >     easier if one assumed that the only method for cbind was
> >     cbind.data.frame...
> > 
> >     Note that by the above logic, if you make a cbind.ts, you can't
> >     cbind a time series to a data frame!
> 
> That's OK, as I can coerce a data frame to a ts, but in general I want to
> cbind ts objects with non-trivial time bases.
> 
> I don't think documenting what we have is a good way out here....

Agreed. But if you want it in 0.65 don't expect me to do it. I'll be
away for the weekend and fly to ISI/Helsinki on Tuesday.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


cbind is not generic as claimed, omits labels where S has them (PR#240)
Peter Dalgaard BSA