- From: Stan Devitt <jsdevitt@maplesoft.com>
- Date: Mon, 16 Mar 1998 08:45:28 -0500
- To: "'roconnor@uwaterloo.ca'" <roconnor@uwaterloo.ca>, www-math@w3.org
The following remarks pertain to some of the questions recently raised concerning the choices made for the content markup described in chapter 4 of the proposal. I would agree with Richard Fateman's remarks to the effect that that the issue of storage formats, or for that matter transmission formats have not been addressed. Nor is it intended that they be at this level. MathML is a textual description which for purposes of content markup lays bare the opportunity to associate specific semantics with constructs and which is directly accessible over the web. Speaking for myself, one of the reasons I believe no alternative column representation was introduced is that there is a gain in simplicity through always representing an object in only one way. A row based representation was chosen since it is consistent with, for example, matlab and other systems. As Richard points also out, it is already possible to describe a particular column, through the introduction of an appropriate operator (by way of the lambda and declare constructs.) The transition from reliance of basic constructs to use of the extendability of the system must occur at some point. The question is where? Remember also, that no "evaluation" ever takes place in MathML. Thus, an author who wanted an actual column to appear would need to provide the column explicitly rather than an operator describing how to construct it. The author who wanted the construction, would provide the construction, in which case implementation occurs at the application end. Stan Devitt > -----Original Message----- > From: Russell Steven Shawn O'Connor > [SMTP:roconnor@wronski.math.uwaterloo.ca] > Sent: Friday, March 13, 1998 11:18 PM > To: www-math@w3.org > Subject: Re: matrixcol element > > On Fri, 13 Mar 1998, Richard J. Fateman wrote: > > > you mean matrixcol(m,c) = matrixrow(transpose(m),c) or some such. > > If we had an appropriate object-oriented approach, then optional > > methods could trade off between storage /access / time . Frankly, > > I never thought of any of the openmath / math-sgml etc as dictating > > either storage formats, access efficiency, etc. Just an inefficient > > textual suggestion of what people might plausibly interpret the > > same way in spite of having different basic assumptions. > > I often think of the columns of a matrix to be more important than the > rows. Mainly this is due to the fact that e_i maps to the ith column > of a > matrix. So when I construct a matrix I likely know its column vectors > and not its row vectors. > > This is refected when you see matrices written as: > _ _ > | | | | | > A = | V_1 | V_2 | ... | V_n | > |_ | | | _| > > which is far more common that a row vector form. > > This is where my thoughts of matrices alternately being defined by > columns > comes from. I don't know if there is time to put this idea into > version > 1.0 of MathML > > -- > Russell O'Connor roconnor@uwaterloo.ca > <URL:http://www.undergrad.math.uwaterloo.ca/%7Eroconnor/> > "And truth irreversibly destroys the meaning of its own message" > -- Anindita Dutta, "The Paradox of Truth, the Truth of Entropy"
Received on Monday, 16 March 1998 08:48:39 UTC