R-alpha: 'Matrix' & 'matrix' Class

[Kurt Hornik]

>>>>> Martin Maechler writes:

> 	we are discussing, yes? -- 
> 	please nobody feel hurt just  because I disagree so heartily
> .. ;-)

I certainly don't.

>>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes:

TL> On Tue, 12 Aug 1997, Ross Ihaka wrote:
>>> There have been a few prods to create an S-like matrix class for R.
>>> A major reason for having a matrix class seems to be that people get
>>> bitten by the default behavior of the drop= parameter to "[".

> I think there are quite a few other reasons. I've been wanting to have 
> a 'matrix' class for other reasons for quite a long time.
> (One that come to my mind:
> 	Kurt's (and my earlier) proposal for a generic  "write" function
> 	with a write.data.frame  method would be much
> 	cleaner to implement with a write.matrix method when matrix was
> a class)

Yes, exactly.  It seems stupid to have to write code like

	xxx.default <- function(obj, ...) {
          if (is.matrix(obj)) {
             xxx.matrix(obj, ...)
          } else {
             ...
          }

(Not only with e.g. the generic write function ... there are many more
examples.)

>>> That being the case does it make sense to change the semantics of "["
>>> rather than introducing a new class?

> I don't think so. (see above and below)

TL> I think changing the semantics is preferable, in part because it
TL> fixes the drop problem automatically, rather than requiring
TL> everyone to use a new feature.  Creating a Matrix class would not
TL> fix the array problem for arrays of dimension 3 or more, either.

> I disagree (I think this is a rare thing with you Thomas..).
> ----------
> 1) Lest I misunderstood something,
>   you mean that	for matrices 'x',
> 	  x[,1]
>   would be a 1--column matrix instead of a vector ?
>   IMHO, this is ugly, and is really just logical if you come from a strict
>   matrix thinker's corner which is the case for  matlab users, and maybe even
>   mathematicians and the like (I'm one myself),
>   but not for an average person analyzing  statistical data.

Exactly.  Having done statistics with Octave prior to the existence of
R, I can only say that `strict matrix thinking' is terrible.  (In
particular, having to worry whether something is a row or a column
vector, when it DOES NOT MATTER AT ALL!)

> 2) I'm quite convinced that this will break quite a bit of existing code,
>    maybe code outside the R 'base' source, but still.

>    It is more basically incompatible to S semantics than many other things,
>    I think.

> 3) What if  x  is a data.frame? Would  x[,1] still be a data.frame?
>   If not (which I presume), wouldn't this be contrary to the idea which I
>   teach to beginners that
> 	``data.frames are just matrices, but a bit more general since
> 	  they can contain both numbers and character codes''

Right!

> All in all, the use of  ``drop = FALSE'' is one way to avoid the problem,
> and I agree there should be others,
> (namely a  'Matrix' class in "R base" INDEPENDENT of the Matrix
> library.)

> I do like the  class approach in any case and would like to have
> 'matrix' be THE generic class for all matrices 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [[I've advocating this even for S-plus,
>   years ago, before 'Matrix' came into existence]]

Again, definitely right!

> Then, 'Matrix' would be a class inheriting from 'matrix' with 
> at least it's own "].Matrix" method.

Exactly.

TL> However, a Matrix library might be a nice place to put matrix
TL> features that not everyone needs. This helps keep the size of R
TL> down.  Libraries that can be loaded and unloaded seem like the
TL> ideal place to put a whole lot of things, rather than taking the
TL> S-PLUS approach of bundling gam and trees and nlme and everything
TL> else together.
> yes. {also see above: 'Matrix' would be a class ANYWAY, for the
> 	``[,1] ==> Matrix''   aficionados}

> Especially that we now have require() and provide()  
> [[ provide  has been  fallen out of the source recently,
>    it is "back again" and should appear in the next (pre)release
> ]]


> This is an important discussion - I think -
> so please tell me why you disagree...

> --- Martin

-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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-