R-alpha: 'Matrix' & 'matrix' Class
Martin Maechler
Martin Maechler <maechler@stat.math.ethz.ch>
Tue, 12 Aug 1997 09:32:10 +0200
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-