Core concepts: re-organize trig/log functions?

[NSoiffer]

Summary

We currently have a list of operators listed at the top of the core concept page. I believe that a similar list for common mis that are used for function/concept names should be given. That list would include all of the trig/log functions. It would shrink the size of list by at least two screens.

Proposal

We have previously agreed that it is best if intent is used as low as possible in tree. So

<mrow> <mi>x</mi> <mo intent='plus'>+</mo> <mi>y</mi> </mrow>

is preferable to

<mrow intent='plus:infix($x, $y)'> <mi arg='x'>x</mi> <mo>+</mo> <mi arg='y'>y</mi> </mrow>

Note that ":infix" isn't needed because core says it defaults to ":infix". Also note that in the first case, the intent is not needed on + because there is a unique intent associated with that character.

In a similar vein, it is best to push the intent for functions as low as possible in the tree. So

<mrow> <mi intent="sine">sin</mi> <mo>&#2061</mo> <mi>x</mi> </mrow>

is preferable to

<mrow intent='sine:function($x)'> <mi>sin</mi> <mo>&2061;</mo> <mi arg='x'>x</mi> </mrow>

Consistent with the preference to use the lowest usage, we have a list of operators at the start of core with the intent name along with operators they are associated with. I believe the same should be done for function names. This would result in a list with entries such as

sine(sin, sen), cosine(cos), tangent(tan, tg), ..., hyperbolic-sine(sinh), ...

Doing this would shrink the core concept page by at least two screens. We may want to extend this to many other concept names such as "gcd" making shrinkage even greater. There is a potential problem with "gcd" because it has multiple arguments and the ordering needs to be specified somehow. Perhaps they are only included in the list when the order matches the rendering order (which is the default interpretation). When pushed down to the leaf level, there is no problem.

As with operators, for the first case, one doesn't need to add the intent to sin because sin would have a unique mapping to "sine". Currently, the core concept list does not make this clear or even that it should happen. Of course, just as with +, if someone wanted different speech, they can add intent on the mi.

The current nofix entries would also be in this list -- the nofix entries are not operators -- they should be mis and so are currently wrong.

Other than (maybe) the new default association of the display name ("sin") with the concept ("sine"), this proposal does not change how the concepts for the trig functions (etc) are used. It does however make it clearer that intents for function names are similar to intents for operators in that both can (should) be used on the leaf elements when possible.

[davidcarlisle]

I'm sure we can compress the current display but unless I am missing something you are suggesting dropping the speech templates for each function. Unlike the visual display the speech is somewhat less consistent and there are historic and regional variations, especially for the hypobolic variants sinh pronounced shine for example doesn't follow from any general rule, but is currently explictly listed at https://w3c.github.io/mathml-docs/intent-core-concepts/#hyperbolic-sine1function

[dginev]

The description is somewhat incomplete. While plus is preferable on its carrier <mo>, that doesn't extend to a claim that the parent mrow is preferable bare, without any intent.

The rule would be that MathML 4 trees with intent attributes are generally preferable to MathML 4 trees without that attribute.

So, for Neil's example this would be:

<mrow intent="$op($x,$y)">
  <mi arg="x">x</mi>
  <mo arg="op" intent='plus'>+</mo>
  <mi arg="y">y</mi>
</mrow>

The rest of the issue appears to deal with the inference required to obtain that $op($x,$y) structure. But inference is likely system-specific for this stage of intent and we wouldn't have an expectation for it to interoperate?

[NSoiffer]

@davidcarlisle: the speech for a concept always (potentially) differs from the concept name -- the choice of what to say for a known concept name is up to the AT. A simple example would be that for "cosine", one can say "cos" or "cosine". That's no different than "hyperbolic-sine" where it might say "hyperbolic sine", "sinch", or "shine". The idea is that "sinh" maps to "hyperbolic-sine" and from there AT decides what to say based on locale and user preference. No change from the spec. I do agree that my suggestion loses examples of potential other ways of speaking the concept name. That's true for the operators also (e.g., "cross product" and "cross"). Maybe it is more important for function names though, so the format for that list can't be as compressed?

@dginev: I'm confused about why you think the mrow example I gave is incomplete. I seem to be missing why it is necessary or important to add $op? Your form is of course legal, but the two examples are 100% equivalent for speech and for navigation. There is no inference happening: by how we defined intent, both speak as "x plus y".

[dginev]

I seem to be missing why it is necessary or important to add $op?

Yes because

1. This example is too small to show any of the real-world difficulties with these trees.
2. You may be implicitly assuming an <mrow> convention that isn't part of the intent specification (unless I missed it getting codified?)

Compare the only mildly longer variant:

<mrow intent="$eq($op1(times($two,$x),$op2($three,$y)),$zero)">
  <mn arg="two">2</mn>
  <mi arg="x">x</mi>
  <mo arg="op" intent="plus">+</mo>
  <mi arg="3">3</mi>
  <mo arg="op2" intent="minus">-</mo>
  <mi arg="y">y</mi>
  <mo arg="eq" intent="equals">=</mo>
  <mn arg="zero">0</mn>
</mrow>

Being able to deduce/come up with that intent expression is something I would describe as "inference" if all you had was that single flat mrow with 8 token children.

[davidcarlisle]

@NSoiffer

the speech for a concept always (potentially) differs from the concept name -

well yes but trig functions are typographically pretty much canonically standard layout and unambiguous notation so they wouldn't need to be in core (or even have an intent at all) if it were not for peculiarities in pronunciation that are listed in the speech templates.

[davidcarlisle]

@dginev

Being able to deduce/come up with that intent expression is something I would describe as "inference" if all you had was that single flat mrow with 8 token children.

But in that case the system doesn't have to infer that intent expression

<mrow>
  <mn>2</mn>
  <mi>x</mi>
  <mo intent="plus">+</mo>
  <mi>3</mi>
  <mo intent="minus">-</mo>
  <mi>y</mi>
  <mo intent="equals">=</mo>
  <mn>0</mn>
</mrow>

is simpler markup to generate and much simpler markup to process to generate the required reading, so generally it's to be preferred.

[dginev]

You lose the vertical axis of navigation (walking up and down a deep tree) if you prefer "simple authoring markup", as that gives you a long flat list of tokens (left-to-right navigation, without an ability to zoom out)

Intent is designed around "expressions", not around "inference". If the expressions are now considered too verbose, I think we should scrap this spec and start fresh.

[davidcarlisle]

@dginev it's well established that giving more structure with nested mrows is a good thing and helps navigation. I'm not sure that a deeply nested intent expression on the parent mrow would help navigation
if there is no mrow structure. Perhaps it would but I don't think it does currently and it's not specified that it should.

But my point would stand even if intent on the mrow did help, in that if it is omitted the system would not need to infer it, which is what you implied would have to happen.

[dginev]

in that if it is omitted the system would not need to infer it, which is what you implied would have to happen.

I said that trees with intent attributes are generally preferable and this is the (valid) motivation that exemplifies why. Unless the structure is fully specified, vertical navigation is lost as an affordance.

[davidcarlisle]

@dginev

I said that trees with intent attributes are generally preferable

yes that's what you said earlier but I was mostly replying to your later comment, and just observing no inference was happening here, the system doesn't have to infer the missing expression on the containing mrow.

Being able to deduce/come up with that intent expression is something I would describe as "inference" if all you had was that single flat mrow with 8 token children.

But on this comment:

Unless the structure is fully specified, vertical navigation is lost as an affordance.

It's possible that systems implement navigation based on the intent tree when there is lacking structure in the presentation tree, but I don't think they do currently and I don't think the spec implies that they should.
navigation is only lost if it was there originally.

[NSoiffer]

A few comments:

1. Both MathCAT and SRE rebuild the MathML tree and add mrows as they think appropriate.
   • MathCAT would have flattened the plus/minus tree because most people don't think of minus binding more tightly than plus (they are taught PEMDAS in the US).
   • Interestingly(?) there is no equivalent way to mark an mrow with intent so that it is the same as an mrow that has intent on the + and - in it. That's also true for a chain of inequalities (e.g, xxx = yyy < zzz <= abc).
   • MathJax does have minus bind more tightly. That leads to (IMHO) very counter-intuitive navigation. Give it a try: use the context menu and right click to activate accessibility and than tab to the expression, hit return and start navigating the expression.
2. MathCAT and SRE provide "syntactic" tree-based navigation. Other AT systems out there that I know of only provide a means to navigate linear expressions one "thing" at a time (I want to say "term", but that's not technically correct). 2D expressions are an atomic "thing" when moving left/right, but you can zoom into them.
   • MathCAT provides three forms of navigation: tree-based, the semi-character based navigation, and character-based navigation.
   • I believe Murray's unicode math is only-character based, which makes sense for an editor. My memory is that he has commands other than left/right arrow for moving around.

My main point is that while your complicated intent may allow for a tree-based navigation, the spec does not require it, AT may do their own tree inference, and tree-based navigation may not be a user's preferred mode of navigation.

What style of intent does LaTeXML produce, or maybe, what does it's prototype implementation with intent produce? Maybe @brucemiller could chime in if things have changed since you (Deyan) left.

Similar question for @davidfarmer's SpaceMath.

[dginev]

I would also welcome an opinion by @physikerwelt and @Jazzpirate on how they think of structuring the intent expressions for their resources, and if they have a preference on this "expressions" vs "inference" aspect of the spec.

[NSoiffer]

One more comment on tree navigation: it only makes sense to support tree navigation if it works all the time. Inconsistent tree navigation is likely much worse than no tree navigation. Because MathCAT cleans up the MathML and adds structure, it can offer tree navigation as an option. Same for SRE. Because intent may or may not have structure, it is like optional mrows: it can aid in navigation but some other fallback is needed.

[dginev]

Because intent may or may not have structure

This is incomplete for the same reason the issue description was incomplete. An "intent expression" (as per the grammar in the spec) always has sufficient structure for navigation.

A bare presentation node (which lacks any intent), will not have sufficient information for vertical navigation.

[physikerwelt]

@dginev We have implemented a mechanism to empower people to override default intent. My vision is for people to use MathCat or SRE in their browsers to get a full intent tree if needed. But generating that by default for all users doesn't seem reasonable. What do the others think?

For content and non-screen reader activities, e.g., hovering over Formulae, we'll map the elements to Wikidata. Here, the open list is helpful, as it has the links that are currently missing in the full list.