Re: [EXTERNAL] Some braille references

There are some cases where the meaning has influence on the
Nemeth markup, but in my experience those are rare, and it is more
helpful to think of Nemeth as just a translation of what you see,
without regard to its meaning.

Here is an example of when it is different.

The notation
    A:B
for a ratio is common in elementary math, and there is Nemeth
markup for it.

The notation
    [A:B]
occurs in group theory.  Here  A  is a group and  B  is a subgroup.
The notation is pronounced "the index of B in A".
(Yes, I said it correctly: the order of pronunciation is the
opposite of the order you write it.)   [A:B] is a positive integer.

In Nemeth, the  A:B  portion of index notation is not typeset
the same as the ratio A:B .

We discovered this difference when a trained Nemeth translator
was working on an abstract algebra book.

Note that [A:B] is sometimes written |A:B| , so add that to the list
of expressions of the form "vertical line - something - vertical line".



On Fri, 9 Jul 2021, Sam Dooley wrote:

> Any discussion of Braille math should start by observing the truly unique and astounding result
> accomplished by Prof. Nemeth with his Braille encoding for math.  Almost fifty years before any
> of the rest of us recognized the importance of the separation of notation and semantics, in any
> realm of computing, Prof. Nemeth created a Braille linear form for math that captures printed
> math notation in a way that respects its semantic structure.
> As Neil has pointed out, Prof. Nemeth's stated goal was indeed to capture the symbols on the
> page, knowing that if he could "see" the symbols, he could infer the interpretation.
> 
> However, after a careful and thorough analysis of the code, and after implementing a direct
> translation from Content MathML to Nemeth Braille, my experience has been that Prof. Nemeth's
> understanding of the semantics also had a clear influence on the design of the code.  The design
> for nested opening and closing fraction indicators is just one example.
> 
> So in my opinion, Neil's statement that Braille is only encoding the layout, and not the
> semantics, is a bit of an over simplification.  Examples exist where the same printed notation
> results in different Braille encodings, where an indication of the intent of the markup would
> resolve the ambiguity.
> 
> (It's been awhile since I looked at these examples, but I seem to recall that
> degree-minutes-seconds and primes for feet and inches fall in this category.)
> 
> So my hope is that our design for encoding intent would also support Braille translation in a
> natural way, based on the underlying semantics.
> 
> Sam
> 
> On Fri, Jul 9, 2021, 11:55 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>       I agree with Deyan's general point that any notation will be used in ways that differ
>       from what one encounters through lower-level undergraduate math. This means that
>       speech or computation can't make an assumption that will be right all the time even
>       for the mfrac/linethickness case. However, I don't think Deyan's concerns extend to
>       braille in this case. Because braille is encoding the layout, not the meaning, all of
>       those examples that use \atop and do so by generating mfrac with linethickness=0 will
>       have the same braille representation (at least as far as my understanding of Nemeth
>       goes) so a software generator won't have a problem as it will properly generate the
>       "directly under" symbol. If they use mtable (as I'm sure the pmatrix examples would),
>       then the ambiguity for what braille to generate shows up.
> 
> My knowledge of braille math codes really only extends to Nemeth and UEB (and barely
> there), so I don't know for sure about my claims that semantics is not part of braille
> extends to other language's braille codes. I hope to find someone who can answer that
> question one of these days.
> 
>     Neil
> 
> 
> On Thu, Jul 8, 2021 at 9:21 PM Deyan Ginev <deyan.ginev@gmail.com> wrote:
>       Hi Bill,
>
>       Luckily (for me), Neil is overly optimistic on exactly the part you're
>       happy to support, so I can contradict you both in tandem. The claim:
>       "as an mfrac with linethickness=0, there is no problem understanding
>       that it is a binomial to a software translator"
>
>       is only accurate if you've decided this is all you're going to support
>       in your software. And especially in cases using "\atop", rather than
>       "\binom", because - as the name suggests - there is no semantic
>       commitment even in the latex macro, let alone the presentation MathML.
>
>       As is customary, some freshly collected counter-examples from arXiv:
>        -- ( · \atop · ) is used for a column vector;
>          - (C.4) in https://arxiv.org/pdf/0906.3743.pdf
>          - (1,1), Theorem 2.4, (2.21),... in https://arxiv.org/pdf/0906.2242.pdf
>          - page 4, in https://arxiv.org/pdf/math/0607411.pdf
>          - (52), (53) in https://arxiv.org/pdf/cond-mat/0609580.pdf
>          - with fractional values, bottom of page 8 in
>       https://arxiv.org/pdf/1112.5353.pdf
>          - (2.9) in https://arxiv.org/pdf/hep-th/0607092.pdf
>          - "spin part" of the wave function after (4) in
>       https://arxiv.org/pdf/cond-mat/0009028.pdf
>          - figure 4 in https://arxiv.org/pdf/1909..07663.pdf
>          - "bispinor", (20) in https://arxiv.org/pdf/1205.6983.pdf
>       --  ( · \atop · ) used to classify Einstein equations:
>          - start of Appendix A, page 12 in https://arxiv.org/pdf/1302.4875.pdf
>
>       -- {pmatrix} used to write binomials:
>          - page 3 of https://arxiv.org/pdf/math/0506006.pdf
>          - specifically: \begin{pmatrix}n\\ i\end{pmatrix} and
>       \begin{pmatrix}m\\ i\end{pmatrix}
>
>       I of course also spotted a couple of binomial uses of \atop along the
>       way (such as https://arxiv.org/pdf/cond-mat/0011360.pdf ), in support
>       of Murray's use.
>
>       I am happy to repeat this point (with examples) as many times as
>       needed. Namely, an assumption that any mathematical notation (i.e.
>       presentation tree) has a *unique* implied meaning is bound to be
>       demonstrably false, when compared against the full body of
>       mathematical writing. It can be a correct assumption if contained to a
>       specific area of writing, such as "K-14 western educational
>       materials". And then we can explicitly enumerate exactly what we mean,
>       with explicit tests and selector patterns. We've discussed such an
>       approach as part of a "Default Intent" effort.
>
>       As to adding "minimal semantic information available in presentation
>       MathML", we first need to answer "serving which applications?". For
>       the accessibility-oriented ones, the discussions about Intent
>       annotations have been making some progress, and it is a good design
>       choice to think of parallel attributes on top/on the side of the
>       presentation tree. As a baseline, communicating exactly what is
>       written has the great benefit of not making false claims about what
>       was meant.
>
>       So, to conclude. "an mfrac with linethickness=0" is clearly ambiguous
>       in arXiv, and can't be defaulted to any one meaning, as far as that
>       corpus is concerned.
>
>       P.S. Side-remark: sometimes an article uses notation so exotic that
>       even knowing that *some* uses of \atop are binomials, still leaves an
>       unsuspecting reader guessing if *all* uses of \atop are binomials, or
>       instead get overloaded for some other purpose. I stumbled on one such
>       document. "Example 21" in it is not for the faint of heart, even if
>       you are fully sighted and prepared to tackle arXiv. Enjoy:
>       https://arxiv.org/pdf/1512.05937.pdf
>
>       Greetings,
>       Deyan
>
>       On Thu, Jul 8, 2021 at 9:37 PM Hammond, William F <whammond@albany.edu> wrote:
>       >
>       > (I may be in a top-posting dungeon for a while.  Sorry.)
>       >
>       > Neil writes:
>       >
>       > If the binomial is represented as an mfrac with linethickness=0, there is no
>       problem understanding that it is a binomial to a software translator. But if it
>       is represented using mtable, then there is nothing to distinguish the two in
>       the presentation MathML.
>       >
>       >
>       > Notice that Neil is saying that there is value in having minimal semantic
>       information available in presentation MathML.  (I've said this before regarding
>       the removal of <mfenced>.)
>       >
>       >            -- Bill
>       >
>       >
>       >
>       > ________________________________
>       > From: Neil Soiffer <soiffer@alum.mit.edu>
>       > Sent: Thursday, July 8, 2021 5:57 PM
>       > To: Noble, Stephen <steve.noble@pearson.com>
>       > Cc: Murray Sargent <murrays@exchange.microsoft.com>; deyan.ginev@gmail.com
>       <deyan.ginev@gmail.com>; ljmaher03@outlook.com <ljmaher03@outlook.com>;
>       www-math@w3.org <www-math@w3.org>
>       > Subject: Re: [EXTERNAL] Some braille references
>       >
>       > I heard back from Susan Osterhaus. Her reply was basically that transcribers
>       typically don't know math well so Nemeth code is designed so that it only
>       reflects the symbols on the page, not the interpretation of them since that is
>       beyond what transcribers typically know. That reminded me of what Dr. Nemeth
>       said of MathSpeak (the way to speak math that resembles Nemeth). His readers
>       didn't typically know much math, so he just wanted them to tell him what was on
>       the page so he could write it in (Nemeth) braille on his braille writer and be
>       able to review it.
>       >
>       > I did come up with one notation where someone needs to make a semantic
>       determination: binomial vs 2x1 column matrix. In Nemeth, a binomial is
>       represented with an open paren,  top part, a "directly under" symbol, followed
>       by the bottom part, and finally a close paren; a matrix would occupy two lines.
>       There might be a single line way of doing a matrix for braille displays, but I
>       didn't see it mentioned.  If the binomial is represented as an mfrac with
>       linethickness=0, there is no problem understanding that it is a binomial to a
>       software translator. But if it is represented using mtable, then there is
>       nothing to distinguish the two in the presentation MathML. Typically the
>       subject area would make it obvious, but in isolation, some hint from the author
>       is needed. The same is true for a sighted reader. Many WYSIWYG editors use the
>       mtable form for binomials, so this is not a theoretical problem, but one that
>       is common in MathML usage.
>       >
>       > Susan Jolly sent me email and reminded me that Nemeth was very thoughtful in
>       his choice of dot patterns so that they would be more intuitive. For example,
>       here is a fraction (recall a braille cell is 3x2 dots):
>       > ⠹⠆⠌⠒⠼
>       >
>       > There are five braille cells in the expression. The first and last cells are
>       the start and end fraction symbols and the middle cell is the 2D  "/". The full
>       column for the start/end is like a fence for fingers and the middle symbol
>       resembles the slash, so this can be easily(?) recognized as a fraction. FYI:
>       the numerator is a '2' (a "dropped" b ['b' starts in the first row, not the
>       second]) and the denominator is a 3 (a dropped c). Another example of an
>       encoding choice that resembles the print form is '=' which has the two
>       character braille representation "⠀⠨⠅⠀" ("that is a "⠨" and a "⠅" character
>       with a blank before and after it). That's your braille lesson for today :-)
>       >
>       >     Neil
> 
> 
>