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

[Martin Maechler]

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


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

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

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


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

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

    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


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