Re: Stretchy equal sign for commutative diagrams

Dear Frédéric,

I would agree heartily with what Ross says about the semantic marking of
arrows in commutative diagrams.  The extra long equals that is used from
time to time, often just to straighten up other arrows by essentially
duplicating a node (say to make a square out of a triangle), doesn't seem
to me essential.  Of course, the equal sign actually introduced by Robert
Recorde had by present-day standards very long bars,  say about 5 times
longer than today, i.e. 8em or more---see
http://www.jstor.org/discover/10.2307/27955396?uid=3738128&uid=2&uid=4&sid=21102045047697

It could be argued that there should be a character for a stretchy double
arrow body (without a head), but we have never been able to get the
idea of a full arrow kit adopted, although it would be much more flexible.
By this I mean the arrow equivalent of the piece collections for stretchy
parens, brackets etc.  That and a consistent use of direction-changing
operators generalizing the bidi one in Unicode, to say a dihedral group
of order 16, would have greatly reduced the number of characters needed,
increased flexibility, and could have simplified implementation.  

In general though, I'd suggest that a combination of SVG for larger
diagrams and MathML for equational decorations (the whole possibly to be
viewed as a math object) should be the way to go.  This applies to
operators in cartouches, such as occur in some algebraic papers, and I'd
say to such things as braid group calculations, although there are now
fonts for them around, I think.

There are going to come situations where there are active three- or
more-dimensional commutative diagrams being bandied about, I guess.
Spectral sequences and associated lemmas (e.g. 5- and 9- et al.) and the
sort of triangles used in contexts with derived functors like, say,
Kashiwara's also make for difficult composition, but I can imagine
wanting to set up dynamic illustrations of calculations with them
featuring waves of changes across the diagram as more and more becomes
clear when the required special cases of general rules are reckoned.
After all that's how the results are actually worked out, so that would
just be a little more fancy example of the injunction to `show your
work'.  But we don't yet have a markup that is clearly well-suited
to these situations, so there's no implementation problem.

I applaud with enthusiasm your important continued push to implement
more of MathML right. The Math WG is deeply in your debt, but it's
no doubt the benefit to the math community that's most significant.

All the best,

Patrick

On 3/25/13 10:50 PM, Frédéric WANG wrote:
> Hi Ross,
>
> Thanks for you feedback.
>
> I should say that I'm considering the AMScd package, so very basic
> commutative diagrams. For more complex diagrams, I don't think it's a
> good idea (or even possible) to use pure MathML but it's better
> instead to rely on SVG for the graphical elements. IIUC, that's what
> does XyJax (Xy-pic package for MathJax) or another package being
> developed for LaTeXML.
>
> AMScd only implements diagrams with vertical/horizontal arrows. So
> here we can just use a table with stretchy operators inside. All
> arrows and bars usable in AMScd are already defined stretchy in the
> MathML operator dictionary. Only the case of the equal sign is not
> clear, thus my message.
>
> On 25/03/2013 21:34, Ross Moore wrote:
>> Hi David, and others.
>>
>> When designing and developing Xy-pic, many years ago, we decided that
>> the most convenient representation was putting an '=' as a label
>> above a single line, with all the stretchiness being in the line.
>> This fits with labeling using other characters for different special
>> meanings.
>> Authors can choose to use a double line, if they like, but although
>> the spacing between the lines can be controlled, there is no easy way
>> to match it to the actual separation of a specific font character.
>> The syntax to use a double line is quite different to that of placing
>> a single character.
........

Received on Tuesday, 26 March 2013 09:16:17 UTC