# RE: [EXTERNAL] Re: Minutes: MathML Core meeting July 27, 2020

David’s case

<mrow><mo>|</mo> zzz  <mo>|</mo> zzz <mo>|</mo></mrow>

is a bit bizarre. How would you speak it? Do the outer |’s mean “absolute value”? In which case, what’s the inner | mean? I’ve struggled with the ambiguities of the vertical bar over the years. It’s true that with clever parsing of the <mrow>, you can figure out that the first | is an opener, the middle is binary of some sort and the final | is a closer. This example is clearly for illustration only, since it doesn’t appear to represent a mathematical construct.

But getting back to my expectation-value example, how do you know what the vertical bars in ⟨Ψ|ℋ|Ψ⟩ mean? Are they separators or absolute values? As a physicist, I’d recognize this expression as a quantum mechanical expectation value and know that the vertical bars are separators, but without that context, the vertical bars have to have an attribute like separator=”true” to be unambiguous.

Murray

-----Original Message-----
From: Deyan Ginev <deyan.ginev@gmail.com>
Sent: Tuesday, July 28, 2020 7:33 AM
To: David Carlisle <davidc@nag.co.uk>
Cc: Murray Sargent <murrays@exchange.microsoft.com>; public-mathml4@w3.org
Subject: Re: [EXTERNAL] Re: Minutes: MathML Core meeting July 27, 2020

@Neil: thanks for mentioning "form" ! @David: Thank you for the great TeX walkthrough, very helpful!

So, reading the "form" spec text, there is indeed an available alternative to "separator=true" with "form=infix", while \left| and \right| would have form=prefix and form=postfix respectively, instead of fence=true.  On top of that, it is already a default behavior when the fenced notation is wrapped by an <mrow>, nice and tidy.

I guess the remaining contention then is how to properly mark up an <mo form="infix">|</mo>, so that it can have a different appearance when used as a decorative glyph of a mixfix notation (the Dirac notation example), contrasted to the nicely spaced out \mid-like use, where the vertical bar is a standalone infix relation between two arguments.

Is the suggestion to handle this with explicitly setting lspace and rspace in the cases where the <mo> is an infix relation, while the default is the "tightly spaced" rendering?

Greetings,
Deyan

P.S. I am realizing now that I've caught up to the beginning of this email thread. Apologies for which. In the most optimistic scenario this may have helped some of the other silent readers get to the bottom of what this particular deprecation is about.

On Tue, Jul 28, 2020 at 4:32 AM David Carlisle <davidc@nag.co.uk> wrote:
>
> On 28/07/2020 01:36, Deyan Ginev wrote:
>
> Hello,
>
> I am trying to follow the discussion, and would love to ask for help
> with clarifying the terminology/use cases here.
> Paging through the TeXbook, it appears to me vertical bars are given
> three independent treatments - 1) simple symbol |, 2) middle fence,
> e.g. \middle|, \bigm| and 3) relation: \mid. I'm attaching a tiny PDF
> file that shows the (indeed visible!) differences between the four,
> when there is a proper 2D object to delimit.
>
> The situation in (e)TeX is "complicated"  tex has
>
> mathord, mathopen, mathclose, mathbin, mathrel with typical examples
> being  x ( ) + =
>
> \bigl| \bigm| \bigr |  are big sized | with respectively mathopen mathbin and mathclose spacing.
>
>
> in almost all cases that you want arbitrary size delimiters and use
>
> \left|  \middle|  \right|
>
>
> (where \middle is an etex extension not in the texbook) you'd like them to have mathopen mathbin and mathclose spacing but unfortunately they don't:
>
> \left\right make a mathinner atom which has similar but different
> spacing to a group surrounded by mathopen and mathclose
>
> and \middle makes a mathord.
>
>
> In luatex you can specify the class of stretchy delimiters but other
> engines you typically see explicit spacing around stretchy delimiters
> or constructs such as
>
> \mathbin{}\!\middle\|\mathbin{}
>
> which effectively gives a stretchy middle | with \mathbin spacing.
>
>
> \mid is equivalent to   \mathrel|
>
>
>
>
> So, I think I am reading Murray's examples as if separator=true in the
> Dirac notation maps onto \middle|, i.e. "a middle fence", and
> fence=true for bra and ket maps onto \right| and \left|.
>
>
> Yes except the mathml3 attributes were explicitly not about spacing, so you need to arrange the spacing another way they would get the equivalent spacing already by default in mathml by being the first or last or inner items in an mrow.
>
>
>
> As someone who had to learn the meanings of "fence", "separator" and
> "delimiter" as a second language, I will confess to having undergone
> some significant confusion in building a mental image where the three
> words aren't outright synonyms. In colloquial English it appears that
> fences were used very early on to separate fields, and hence delimit
> them. On the other hand, I will also confess I have never had any
> confusion with understanding "left", "middle" and "right" as distinct
> concepts.
>
>
> Yes sorry English is rubbish:-) I don't think there is any difference between fence and delimiter here.
>
> TeX the language doesn't use "fence" at all, it calls these things
> delimiters, the texbook only uses the word fence in an index entry
> which says, in full,
>
>
> fences, see opening, closing, delimiters
>
> I think it's quite reasonable that the various uses of vertbar should
> be expressible in (normative) presentation MathML, as Murray suggests,
> so there should either be 1) an alternative representation with
> spacing/sizing directives, or 2) the a11y attributes would need to
> become normative (which is unlikely from what I understand), or 3) the
> status quo must be maintained.
>
>
> As I say above I think that's a misunderstanding as
>
> <mrow><mo>|</mo> zzz  <mo>|</mo> zzz <mo>|</mo></mrow>
>
>
> already gives mathopen mathbin and mathclose spacing for | without any
> attributes, the
>
> existing fence= attribute was _not_ about spacing but about giving some semantic hints.
>
> Greetings,
> Deyan
>
>
>
> David
>
>
>
>
> Disclaimer
>
> The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice for information on how we process personal data and for details of how to stop or limit communications from us.
>
> This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.


Received on Tuesday, 28 July 2020 18:55:17 UTC