R devel - Aug 1999 - cbind is not generic as claimed, omits labels where S has them (PR#239)

(1) ?cbind claims

     The generic functions `cbind' and `rbind' take a
     sequence of vector and/or matrix arguments and combine
     them as the columns or rows, respectively, of a matrix.

Note:

     The method dispatching is not done via `UseMethod(..)',
     but by C-internal dispatching.  Therefore, there's no
     need for, e.g., `rbind.default'.

but my cbind.ts does not get called, and try the following:

cbind.my <- function(...)
{
    stop("used cbind.my")
}
a <- b <- 1:3
cbind(a, b)
class(a) <- "my"
cbind(a, b)
     [,1] [,2]
[1,]    1    1
[2,]    2    2
[3,]    3    3

This is incorrect.

(2) S would give 
     a b 
[1,] 1 1
[2,] 2 2
[3,] 3 3
(and stop on the second cbind call).

and this discrepancy is hardly an improvement!

Could someone who can understands the c/rbind code please sort this out.
(It looks pretty arcane to me, and surely should not be special-casing data
frames.)

I used both of 
> R.version
           _                   
platform   sparc-sun-solaris2.6
arch       sparc               
os         solaris2.6          
system     sparc, solaris2.6   
status                         
status.rev 0                   
major      0                   
minor      64.2                
year       1999                
month      July                
day        3                   
language   R                   
> R.version
           _                           
platform   sparc-sun-solaris2.6        
arch       sparc                       
os         solaris2.6                  
system     sparc, solaris2.6           
status     Under development (unstable)
status.rev 0                           
major      0                           
minor      65.0                        
year       1999                        
month      August                      
day        05                          
language   R                           



-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


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

ripley@stats.ox.ac.uk writes:
> (1) ?cbind claims
> 
>      The generic functions `cbind' and `rbind' take a
>      sequence of vector and/or matrix arguments and combine
>      them as the columns or rows, respectively, of a matrix.
> 
> Note:
> 
>      The method dispatching is not done via `UseMethod(..)',
>      but by C-internal dispatching.  Therefore, there's no
>      need for, e.g., `rbind.default'.
> 
> but my cbind.ts does not get called, and try the following:
> 
> cbind.my <- function(...)
> {
>     stop("used cbind.my")
> }
> a <- b <- 1:3
> cbind(a, b)
> class(a) <- "my"
> cbind(a, b)
>      [,1] [,2]
> [1,]    1    1
> [2,]    2    2
> [3,]    3    3
> 
> This is incorrect.
> 
> (2) S would give 
>      a b 
> [1,] 1 1
> [2,] 2 2
> [3,] 3 3
> (and stop on the second cbind call).
> 
> and this discrepancy is hardly an improvement!
> 
> Could someone who can understands the c/rbind code please sort this out.
> (It looks pretty arcane to me, and surely should not be special-casing data
> frames.)
Hmm. 

(1) The docs are clearly wrong (or perhaps rather, wishful thinking)

(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))))

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

On Thu, Aug 05, 1999 at 01:28:05PM +0200, ripley@stats.ox.ac.uk
wrote:
> Could someone who can understands the c/rbind code please sort this out.
> (It looks pretty arcane to me, and surely should not be special-casing data
> frames.)
[ That would be a member of an empty subset of the developers. :-) ]

I can see what the problem is - we don't have the generic dispatch
mechanism in place.  I will add it.

I think that the special casing of data frames is needed because this
appears to be the (undocumented) S behaviour.  A data frame anywhere in
the argument list causes the result to be a data frame.

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

On Fri, Aug 06, 1999 at 12:08:05AM +0200, Peter Dalgaard BSA
wrote:
> Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:
> 
> > I can see what the problem is - we don't have the generic dispatch
> > mechanism in place.  I will add it.
> > 
> > I think that the special casing of data frames is needed because this
> > appears to be the (undocumented) S behaviour.  A data frame anywhere
in
> > the argument list causes the result to be a data frame.
> 
> I played around with this earlier today. There's nothing special about
> dataframes, S does the same with any classed object. I.e.
> 
> class(b)<-"my"
> cbind.my<-function(...)match.call()
> 
> cbind(a,b)
> 
> will dispatch cbind.my
Yetch!  What happens when there are conflicting classes I wonder.
[ Rhetorical question. ]

It sounds like this might make things easier.

	Ross

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

On Fri, Aug 06, 1999 at 12:08:05AM +0200, Peter Dalgaard BSA
wrote:
> Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:
> 
> I played around with this earlier today. There's nothing special about
> dataframes, S does the same with any classed object. I.e.
> 
> class(b)<-"my"
> cbind.my<-function(...)match.call()
> 
> cbind(a,b)
> 
> will dispatch cbind.my
I played some more.  I think data frames are special somehow.

	S> x <- factor(1:10)
	S> y <- data.frame(1:10)
	> class(x)
	[1] "factor"
	S> class(y)
	[1] "data.frame"
	S> class(cbind(x,y))
	[1] "data.frame"
	S> class(cbind(y,x))
	[1] "data.frame"

They seem to overpower other class arguments too.

	Ross


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

Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:
> On Fri, Aug 06, 1999 at 12:08:05AM +0200, Peter Dalgaard BSA wrote:
> > Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:
> > 
> > I played around with this earlier today. There's nothing special
about
> > dataframes, S does the same with any classed object. I.e.
> > 
> > class(b)<-"my"
> > cbind.my<-function(...)match.call()
> > 
> > cbind(a,b)
> > 
> > will dispatch cbind.my
> 
> I played some more.  I think data frames are special somehow.
> 
> 	S> x <- factor(1:10)
> 	S> y <- data.frame(1:10)
> 	> class(x)
> 	[1] "factor"
> 	S> class(y)
> 	[1] "data.frame"
> 	S> class(cbind(x,y))
> 	[1] "data.frame"
> 	S> class(cbind(y,x))
> 	[1] "data.frame"
> 
> They seem to overpower other class arguments too.
This is because there's no cbind.factor:

S> cbind.factor<-function(...) match.call()
S> cbind(x,y)
      x           y 
X1.10 1 numeric, 10
attr(, "names"):
[1] ""      "X1.10"
Warning messages:
1: Incompatible methods ("cbind.factor", "cbind.data.frame")
for "cbind"
2: Number of rows of result is not a multiple of vector length (arg 1) in: cbin
	d(x, y)

(and cbind.data.frame just calls data.frame(...) so it's little wonder
that the result is always a data frame)

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

From ripley@stats.ox.ac.uk  Sat Aug  7 09:49:12 1999
	Date: Fri, 6 Aug 1999 22:49:07 +0100 (GMT Daylight Time)
	From: Prof Brian D Ripley <ripley@stats.ox.ac.uk>
	To: Ross Ihaka <ihaka@stat.auckland.ac.nz>
	cc: r-devel@stat.math.ethz.ch
	Subject: Re: cbind is not generic as claimed, omits labels where S has them
	 (PR#239)
	MIME-Version: 1.0

	On Sat, 7 Aug 1999, Ross Ihaka wrote:

	> Ok, I have made some changes to cbind/rbind which will support
	> dispatch to other methods.  As part of this I have changed
	> things so that the values passed on are packaged up as
	> (evaluated) promises so that any closure they invoke will
	> be able to use substitute to get text values

	Sorry, are you using `closure' to mean `method' in S (and I thought R)
	terminology? (I thought a function closure involved the environment....)

Technicality : I mean interpreted function.  I'm disallowing dispatch
to functions without at least an interpreted wrapper.  I don't think
this is a real restriction.

	> to use as labels.  What I need is a clear idea of the rules for doing
	> the dispatch.  The picture I have at present is:
	> 
	> 	dispatch.class <- "default"
	> 	for (arg in arg.list) {
	> 		if (arg is an object) {
	> 			arg.class <- class(arg)[1]
	> 			if (there is a method for arg.class) {
	> 				if (dispatch.class == "default")
	> 					class <- arg.class
	> 				else if (args.class != dispatch.class)
	> 					drop through to dispatch
	> 			}
	> 		}
	> 	}
	>     dispatch:
	> 	if (dispatch.class != "default")
	> 		dispatch to appropriate closure
	> 	else
	> 		carry out default actions
	> 
	> This also looks like it sufficiently generic that it could be packaged
	> as a useful function along the lines of "DespatchOrEval" --
perhaps
	> MultiDespatchOrEval.
	> 
	> Does this sound right?

	`right', huh?  That's hard. I had been thinking about multiple
	classes, which bedevil all this (and JMC got rid of for that
	reason, I guess). I think your rules says choose the class of
	the leading argument whose first class has a method, and I
	think that is wrong. Suppose my two args both have class
	c("mts", "ts") and there is no cbind.mts. Then you will
	dispatch the default, even though the normal rules for
	dispatching on the first arg would dispatch cbind.ts.

	I suspect we need to try more than the first method, but have
	no clear picture of what is right. I would dispatch on the
	first arg that had a usable method.

I think I'm shooting for S compatibility here (I'm firmly in both the
compatible and non-compatible camps -- trying to please everyone I
guess).  I believe Peter described what S3 appears to do, and the
above  is my interpretation of what he said.

I think trying to do inheritance by traversing the class vectors
might be asking for trouble.  It would certainly be significantly
more complex and probably slower.

Taking the first arg with a usable method means that cbind(a, b)
could be a significantly different class of object from cbind(b, a).
This is sometimes a nasty surprise for people.  The S3 philosophy
seems to be that in cases of conflict you ignore classes entirely.
That does give a symmetric result.

	Ross


[ Duncan and I talked about implementing a new kind of object system
  -- different from either S3 or S4.  It would look a little more like
  Java.  Definitely a Version 2 project. ]

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