Re: [EXTERNAL] Some braille references

@David: thanks for the example. I have to say I'm stunned by this as it is
*highly* unlikely a braille translator would know anything about group
theory so they wouldn't be familiar with the notation. Perhaps the issue is
that a ":" inside of brackets is written differently, although I'm really
dubious about that. Is there any chance you can find how it was translated?
I searched several sites and all of them (including the green book) all use
the same dot pattern for ":" (a two cell pattern "⠐⠂" -- dot 5, dot 2)  for
all the examples they show (not just ratio). E.g., "f:(x,y)" and "{x:
x>10}". The only issue I found on the web with ":" is whether it needs
spaces around it or not. When spaces get used in braille is a subtlety that
is beyond my level of braille knowledge, but they seem to be used to make
clear what the braille symbol represents (especially because there are many
multi-cell characters so ambiguities reading the braille crop up which
spaces can resolve).

Note: back translation of Nemeth requires a back tracking parser because
context is needed in some cases to understand what the braille cell(s)
represent. Again, something Sam can provide examples of if people are
interested. It's not relevant for the MathML -> braille question about
whether author intent is needed to do the translation.

    Neil




On Fri, Jul 9, 2021 at 12:18 PM David Farmer <farmer@aimath.org> wrote:

>
> 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
> >
> >
> >