RE: matrixcol element

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