Re: small samples

Response to Ping's comments:


py> Just a couple of notes about the MINSE forms:
py> 
py> rw> Item 1 / simple subscript
py> rw> -------------------------
py> rw> 
py> rw> TeX:            x_1
py> rw> Wolfram:        x_1
py> rw> MINSE:          x;1 or x .dnidx 1
py> 
py> The current name for the ; operator is "idx", so that'd be "x .idx 1".
py> There are actually three options --
py> 
py>     'idx(x,1)        x .idx 1        x;1
py> 
py> -- the second of which is introduced by the shortcut of infix notation,
py> and the third by the further shortcut of an operator symbol.


It's good to point out the 3 options you do, although, as in Dave's comment,
I think we have to give up the notion of "all" possibilities.  I'll carry
the 3 you mention in the "archive" of examples in the AMS pages.  Thanks
(and thanks for the correction on the ^ operator).

I used ".dnidx" simply because you had inserted an ".upidx" in the example
from an AMS journal posted several weeks ago.  This segues into:


py> rw> Item 2 / nested subscript
py> rw> -------------------------
py> rw> 
py> rw> TeX:            s_{i_k}
py> rw> Wolfram:        s_i_k
py> rw> MINSE:          s;(i;k) or s .dnidxa (i .dnidxb k)
py> 
py> I'm not very clear on why you would need to separate the two indices
py> by using different compounds here, but as it stands the two alternatives
py> aren't equivalent.  Probably most equivalent to the other examples would be:
py> 
py>     'idx(s, 'idx(i, k))        s .idx (i .idx k)        s;(i;k)

I used different notations for the indexing operation because I felt
there might be cases where separation of the two maps would be useful.
The "indexing" may be, in both cases, a map from the integers (or
positive integers or non-negative integers), but the maps themselves
are actually different (they may have obviously different ranges).  If
we encountered a complicated expression using the two notions, mightn't we
want them distinguished?  You also say in the second posting:

py> The only reason for the distinction between ".idx" and
py> ".upidx", for example, is that sometimes a raised index
py> and a lowered index have no difference in meaning at all,
py> but are rendered that way just for stylistic reasons,
py> so it is convenient to allow a couple of alternatives.

and I had meant the use of ".dnidxa" and ".dnidxb" in this spirit
(also with semantical distinctions in mind).


I may not be following why you call the two forms I posted
"inequivalent".  I would claim that the second ("s .dnidxa (i .dnidxb
k)") is more highly disambiguated than the first (using the language
of algebraic geometry, one might call the second a "blow up" of the
first) and hence inequivalent, but I'm not certain whether this is
what you allude to.


And last in this list:

py> Another possibly significant point to make is that, while
py> the examples were entitled "subscript", "superscript",
py> and such, the MINSE samples represent the mathematical
py> relationships typically rendered as sub/superscript
py> (e.g. exponentiation), and do not directly mean "superscript".

Yes.  This lies at the base of some fundamental differences in
approach.  Bruce has termed the Wolfram approach "notational"
and MINSE "semantical".  I've tried to indicate a mitigation
by claiming the two don't enforce their differences, but rather
show differences of their authors' attitudes.  This difference
in attitude does come out, as you suggest, in my choice of
category heads.

How to recognize this difference and still work toward HTML-Math?  I
think we can go at this by discussing notations and attaching
semantical cues to notations.  MINSE does it by inserting new
compounds; Wolfram does it by inserting macros or matching patterns
after the expression is formed; I might do it by inserting new
entities orthogonal to the Wolfram scheme:

  MINSE:   x .idx i
  Wolfram: x \idx i
  Whitney: x &semantics{indexer}_ i

(Here I'm only suggesting an extension of the idea of ⁢.)

The reason I would choose to categorize by notation and attach
semantics afterward is because I view the semantical problem as much
thornier and because we know we have to come up with notation which
meets the needs of users who wish to keep semantics in the eyes and
ears of the beholders.

Can we operate in this way, recognizing differences?  If you feel this
closes doors, do say so.  I'm not inclined to attack semantics as
OpenMath and Pike are doing, but I don't think I've ruled out other
ideas of MINSE.

-Ron