Open NSoiffer opened 1 year ago
The terse forms (especially 2 and 4, but also 3) are more or less just reading the characters of the underlying notation, which is a mode hopefully offered anyway, so I'm not sure you need multiple concepts, just first-derivative
of arity 2 or 1 (when the variable the differentiation is with respect to is implicit) or we could just have have derivative
with an additional order parameter,1
as presumably that will be needed anyway for $d^n y/dx^n$
This is a brainstorming comment from me. First, my usual observation is that the information about "which notation was used" is already available in the Presentation MathML tree.
Thinking from first principles, this problem has an analog in the simplest "divide" concept. I'll explore that as it is a little less slippery than the larger differential notations. So, division has at least 5+ notations in common use: $1 / 2$, $1 \div 2$, $\frac12$, $1:2$, $2\overline{)1}$.
Inventing an intent concept list of "divide-slash", "divide", "divide-fraction", "divide-colon" and "divide-long" seems counterproductive here (reason: it feels ad-hoc, while mixing together concepts with notations). At the least it is a new kind of convention that we haven't agreed on yet. What seems mildly more practical is to anchor the standard concept "divide", and have AT be able to consult the presentation tree, in order to determine which notation was used.
As some kind of a "stretch goal", very verbose generators may decide to explicitly call out detected notations as properties. This is my chief point for this comment - the way some of the group members have leaned on :prefix
, :postfix
, :infix
, :function
, and :silent
appears to be on the lines of "notational annotations via properties, if-and-only-if relevant to vocalization". Following that spirit, if vocalizing as a "fraction" (e.g. speaking "one-half" or "one over two") is key to an AT outcome, and AT can not guess that from the outer <mfrac>
, one could explicitly mark via intent="divide:fraction($numerator, $denominator)"
So, back to the differentiation cases Neil mentions, one could imagine generating concept:property
pairs:
first-derivative:leibniz-notation
first-derivative:lagrange-notation
first-derivative:euler-notation
first-derivative:newton-notation
If that offered significant benefit over the bare first-derivative
concept annotation. And to repeat: adding more information about which notation was used is redundant with information already contained in the presentation tree.
My chief worry is keeping the "concept" naming scheme predictable (and not messy). So if anyone can suggest a consistent naming principle that also addresses notational diversity, I'd be interested to discuss some more.
I agree that it doesn't seem worth encoding into the intent what's already in the presentation. However, it is worth noting that the terse reading, especially any glue words like "by", may be colored by knowing that $dx/dy$ is a derivative rather than a fraction.
Incidentally, there's a variant of Euler, $D_x$, that makes the independent variable explicit.
To me the implied bits are more troubling than the different notations. Derivatives are an interesting parameterized concept where the parameters are often omitted or implied: degree (defaults to 1); the independent variable (implied by context and often different for $a'$ and $\dot{a}$). Even the dependent quantity may be missing for a derivative operator (eg. $d/dx$). It's tempting to propose a single concept derivative
but accommodating and explaining optional parameters is tricky.
I've long been under the impression that if intent
is provided, it should be used independent of the presentation MathML that is there. The obvious exception to that is that any referenced args are used. Based on that, MathCAT converts the presentation tree into an intent tree and the speech is derived from that. If no intent is given, it is inferred (defaulting to the underlying presentation tree if there isn't an inference match).
Because of this, modulo the arguments, all intents look the same to MathCAT. If my assumption is wrong, I can of course change the way MathCAT works. It would be a bunch of work though :-(
I like @dginev's fraction examples: $1 / 2$, $1 \div 2$, $\frac12$, $1:2$, $2\overline{)1}$. One important thing about them is that they likely would be spoken differently. Someone who is blind very likely doesn't want to hear the same thing for /
and Γ·
. It is unlikely a sighted person would speak them the same way. And long division is a very different beast than a fraction. So I feel that they really do want different intents, or as a compromise, properties on them (I'm not that keen about that idea though).
I think the issue here is trying to separate the concept from the semantics. For example, if $\frac12$ and $1:2$ have same concept name, why not use the same concept name for $\frac{1}{\sin(x)}$ and $\csc(x)$? To me the reason is that a concept name is only very loosely tied to the semantics, but very unlike semantics, it is very strongly tied to the presentation. Or to put it another way, a concept name associates speech with syntax. @dginev's use of properties could be considered a clever way to make content MathML and intent
more convertible.
A thought experiment: suppose derivatives, or maybe some of the derivative notations, don't get into core. Would all the notations be lumped into one intent name so that they are always spoken the same? Recall that in open, the AT likely has no knowledge of the intent and really should just speak it according to any properties associated with the name and arguments. If you were Newton, would you want your clever new notation being spoken just the same as that scoundrel copycat Leibniz's notation?
MathCAT converts the presentation tree into
If MathCAT has an early phase where it has visibility over the presentation tree, it should be able to preserve whichever information is relevant. You could even invent :data-mathcat-*
intent properties if you had to. The ability to have multiple properties has given us enough room to carry arbitrary runtime data inside a single intent expression - as long as it doesn't get serialized anywhere untoward.
I think the issue here is trying to separate the concept from the semantics.
The less we talk of semantics, the more clarity we'll have. The "concept names" as I've suggested them tie into language use of STEM practitioners, not into any deep properties or nature of the underlying abstract entities. They are easy to speak because they are actual "names" from real-world practice, and they are intuitive as anchors because they name "concepts" i.e. some abstract entity.
Take that away and you have generic "intent keywords" which could name something different-in-kind for every different keyword.
Would all the notations be lumped into one intent name so that they are always spoken the same? Recall that in open, the AT likely has no knowledge of the intent and really should just speak it according to any properties associated with the name and arguments.
To me it is very hard to answer such general questions about Open, without first settling on what we do with language diversity in general, as posed by the aliasing issue.
Introducing the underscore literals was the stopgap we needed to be able to punt on such questions until we have more real-world experimentation with the Open domain. So far, I personally understood/preferred any Open annotation which isn't an encyclopedic concept to require a _literal-annotation
.
The less we talk of semantics, the more clarity we'll have. The "concept names" as I've suggested them tie into language use of STEM practitioners, not into any deep properties or nature of the underlying abstract entities. They are easy to speak because they are actual "names" from real-world practice, and they are intuitive as anchors because they name "concepts" i.e. some abstract entity.
What is the "abstract entity"? Is it the notion of differentiation or is it the notation used to convey a concept? If the former, than one name concept name suffices for the different notations. If it is the later, then one needs different concept names. As indicated in my original messages, people do often pronounce the notations differently, although they might also pronounce them the same.
Proposed resolution: given a set of notations with βanalogous meaningsβ, if there is a significant pronunciation of a notation that is inappropriate for another, then we should separate the intents of these notations.
As discussed in the meeting last Thursday, I find the proposed resolution by @polx here incomplete without making explicit the organizational principle ("how do we choose an intent name?").
We discussed that language can be messy, where certain concept words carry an additional association with a notation - while others do not. The example was "fraction", which both implies the conceptual "part of a whole" division and the "numerator over denominator" notation. In such cases, using the distinct word as an "intent concept" is workable - so we could add both "divide" and "fraction" to Core.
Less so in differentiation, where the notations actively competed between each other. What is a workable naming principle there? Is it adding the notation author's name before the concept?
As in leibniz-derivative
, lagrange-derivative
, newton-derivative
, ... ?
Is this generally better than having the simple first-derivative
for all cases, and using a clarifying property :leibniz-notation
, :newton-notation
after?
What are other cases where such distinctions appear?
Another exemplary case that comes to mind are the 3 notations for function composition
Can all 3 use a single function-composition
intent concept, or do we need to separate them out? Wikipedia lists out 10 different known pronunciations for $g \circ f$, some of which are clearly not applicable to the other two notations (e.g. "g circle f" and "g round f" only make sense when a circle is inked in the expression).
Edit: added a link to the alternative notations page on function composition.
I think only the 1st & last speech templates are needed here:
$f
$f
with respect to $x
The middle cases are simply that the derivative is applied to $x
.In the Math WG meeting today, we agreed to the following:
intent='derivative(function, order, var)'
. We may add a second two argument form that drops order
for first order derivatives based on experience. However, for now, we are going with a single form.:leibniz
, :lagrange
, :euler
, :newton
. For example, intent="derivative:leibniz($f,2,π₯)
.partial-derivative
. Partial derivatives might use a vector or specify the components of a vector and so take any number of variables.An example of the usage of intent for the derivative: $\frac{d^2 f(x)}{dx^2}$
<mfrac intent="derivative($f,2,π₯)">
<mrow>
<msup><mi>π</mi><mn>2</mn></msup>
<mrow arg="f">
<mi>f</mi>
<mo>⁡</mo>
<mrow intent=":fenced"><mo>(</mo><mi>x</mi><mo>)</mo></mrow>
</mrow>
</mrow>
<mrow>
<mi>d</mi>
<msup><mi>x</mi><mn>2</mn></msup>
</mrow>
</mfrac>
For the record:
On point (1), I disagree that only Leibnitz notation "needs" intent; it depends on the user & use-case. A particular annotator may choose to only add intent to such forms, of course.
On point (2), I would prefer var,order
as the ordering of arguments. Moreover, I would think ahead to allowing intent=derivative($f,$v1,$o1,$v2,$o2,...)
to cover derivatives in several variables. This would also cover what you seem to be aiming for with the comment on partial derivatives (which I don't recall was discussed)
I have a question on whether the first arg to derivative
is function
or expression
. It's a little tricky, since sometimes the expression is split between the numerator and baseline (in Leibniz notation).
The wiki definition has such an example: ${\textstyle {\frac {df}{dx}}(a)}$
read as "the derivative of f with respect to x at a" or "df by (or over) dx at a"
I think there are two other possible variations just for Leibniz notation: ${\textstyle {\frac {df(a)}{dx}}}$ and ${\textstyle {\frac {d}{dx}}}f(a)$. I suspect all 3 variations can use the same intent annotation.
Q: Is this case meant to have intent
derivative(f,x,1)(a)
(function arg) derivative(f(a),x,1)
(expression arg)[Aside] Related syntax. A quick survey shows Mathematica, Maple, Maxima, Sage, Matlab, GeoGebra, Fungrim, CortexJS put the order argument after the variable argument, so maybe that is something to follow, as Bruce suggested. There is some variation - Lean's iterated-deriv puts the order first, even before the function. Scipy has derivative where the order is optional and requires a named key=value n=order
when provided.
Indeed, it needs to be expression, more generally.
Regarding your second point, perhaps all these variant notations want the more explicit intent=derivative(f(x),x)
to disambiguate.
OTOH, these examples also point out that all three arguments (whatever the order :>) could reasonably be omitted:
Alas, all these situations require some special interpretation; But also, alas, they are all quite common near K12 (if not in K12).
@brucemiller wrote:
On point (1), I disagree that only Leibnitz notation "needs" intent; it depends on the user & use-case. A particular annotator may choose to only add intent to such forms, of course.
By "needs", I mean won't be spoken well without intent
: you end up with "dy over dx" which, while not horrible, isn't how people tend to speak it. For the other notations, we agreed they could speak well if read literally. I felt that they all need intent
because someone might prefer a more verbose reading (see first comment), but with the exception of Deyan, I believe the rest of the group didn't share that feeling. Some other notations could use the derivative(f,x,n)
intent mentioned above, but not all. For example, there is no explicit variable of differentiation in the Newtonian notation.
On point (2), I would prefer var,order as the ordering of arguments. Moreover, I would think ahead to allowing intent=derivative($f,$v1,$o1,$v2,$o2,...) to cover derivatives in several variables. This would also cover what you seem to be aiming for with the comment on partial derivatives (which I don't recall was discussed).
You suggested that order in the meeting so that the last argument could be optional. Although the minutes don't capture it, @MurrayIII argued that argument order would be better if it reflected the speaking order. David later added that we should have two and three argument versions rather than an optional argument. I believe that is where that part of the conversation ended. Hence, that's why I wrote what I did.
As for partial-derivative
, I agree pairs are likely better -- my point was that we agreed we need a separate intent for them. What that intent should be is for a different thread.
@dginev wrote:
The wiki definition has such an example: ${\textstyle {\frac {df}{dx}}(a)}$
It does seems like there are notations we haven't considered. Personally, I don't think I've seen that notation before, but I've certainly seen $f'(a)$.
read as "the derivative of f with respect to x at a" or "df by (or over) dx at a"
To me, this different reading means we have to have a different intent. There is no way to point to both the 'f' and the '(a)' with our current intent. I'm not sure it makes it into core though. Have other people seen it used?
I think there are two other possible variations just for Leibniz notation: ${\textstyle {\frac {df(a)}{dx}}}$ and ${\textstyle {\frac {d}{dx}}}f(a)$.
The first is the same as our original example, where y
is $f(a)$ in this case. The second example seems like our original case where there is no $f
("d by dx of [invis-func-applicaiton] ...")
Bruce suggested that maybe all the arguments are optional. I don't think that works. They might be empty/blank, but $\frac{d}{dx}$ drops the function ($f
)argument but maintains the dependent variable ($x
). $\frac{d^2}{dx^2}$ drops the $f
, but needs $x
and $n
. The alternative is to have different names for the various derivative intents.
Sadly, many of these example are pointing to the need to keep thinking about intents for derivatives and keeping the issue open :-(.
On the first point, my disagreement was with the "only", not with the needed. The other notations might read OK w/o intent, but we might expect that they'll eventually read better if they did have intent.
As to the optional-ness of arguments, I should have been more explicit that I meant the arguments might be omitted or blank as you suggest; that is, an empty argument given. So $\frac{d}{dx}$ might get intent intent=derivative(,x)
, or intent=derivative(,x,1)
(or swap if you insist).
And another point that I thought was strongly implied, but perhaps needs to be made very explicit: Whatever scheme we come up with for derivative
must be exactly the same as for partial-derivative
.
There's quite a bit of confusion in the discussion of various variants (misunderstanding of notations or misunderstanding of comments about notation?) The notation $\frac{df}{dx}(a)$ is kinda sloppy since $x$ has magically appeared out of nowhere. The wiki page seems to be using it as equivalent to $f'(a)$ which is actually much clearer. It means take the derivative with respect to the first argument of $f$ (whatever that argument is), and then evaluate the result at $a$. This can easily be expressed in intent as intent=derivative(f)(a)
[or replace derivative(f)
with derivative(f,x,1)
or whatever, if you prefer]. In any case, if the first notation is meant to be the same thing, it can get the same intent, of course.
Meta comment: there's a variety of notations that look quite different, but underlying them are a few basic, common concepts. With that variety, there will inevitably be a bit more complexity than usual, but I think we should be leveraging the commonality to minimize the complexity.
There is no way to point to both the 'f' and the '(a)' with our current intent.
I think it's the usual workaround - we need a wrapping <mrow>
. Adding some XML in the details.
ππ/ππ₯ (π₯) is poorly formed: it should be either ππ(π₯)/ππ₯ or π/ππ₯ π(π₯). Both of the latter are easily parsed (in UnicodeMath anyhow). What I like about the Leibniz derivatives is that they can be parsed, and the intents can be generated automatically for them. You can try them all out in https://murrayiii.github.io/UnicodeMathML/playground/. The content writer doesn't need to do anything extra to get the intents. The other kinds of derivatives all need author mark up of some kind which makes them less likely to get intents. (Btw, ππ/ππ₯ (π₯) could also be parsed, but I don't think it's worth doing since it's not likely to show up much).
@MurrayIII Note that the concrete example isn't reusing the bound variable x
but acts on a chosen point of evaluation a
. You may have seen that alternatively written as:
${\displaystyle \left.{\frac {dy}{dx}}\right|_{x=a}{\text{ or }}{\frac {dy}{dx}}(a)}$
there is some brief text on that use at the Notation for differentiation wiki page.
I am not sure I agree that this should be considered of rarer use. I appear to be getting only hundreds of results for an exact fragment match on $\color{orange}\frac{df}{dx}($ over arXiv. It's still noticeable I think. Here are 5 examples that match the exact pattern - links point to individual MathML equations - arXiv:1008.4502, arXiv:1307.3326, arXiv:1411.7907, arXiv:1911.09378, arXiv:2009.11992.
And I get about a hundred more hits when switching the f
for y
, e.g. arXiv:1805.09796.
Edit: Changing my comment to match some newly gathered data.
fragment | # matches | # documents |
---|---|---|
$\frac{d}{dx}($ | 7927 | 3897 |
$\frac{d f(x)}{dx}$ | 584 | 366 |
$\frac{df}{dx}($ | 306 | 165 |
$\frac{dy}{dx}($ | 83 | 46 |
(source: 2021 arXiv data converted with latexml, 1.57 million STEM documents)
Reading [https://en.wikipedia.org/wiki/Notation_for_differentiation], I think the D notation (apparently not used by Euler) seems parsable. It's more ambiguous than the Leibniz notation, so I'd be inclined generate default intents for it only when the D is a β (U+2145). My UnicodeMathML program generates Leibniz derivative default intents for any of 'dβ βππ'. I think the πβ² and π₯Μ notations are used a lot but are best spoken as f prime and x dot, respectively. One could generate an intent by inferring that πβ²(π₯) is the "derivative of π with respect to π₯". But the listener presumably understands that when hearing "f prime of x" since the content author (should have) stated that before using the notation the first time.
Proposed resolution: We discussed in the meeting today that we needed a special pronounciation for just the Leibniz notation. So my suggestion is that we create a core intent for the Leibniz notation and an intent for the other derivative notations (which may be unary, where no var is mentionend, or binary).
For the Leibniz notation:
For the alternative forms:
We discussed in the meeting today that we needed a special pronounciation for just the Leibniz notation
Was that resolved in any formal way? The more constructive question to me is:
"What should be covered by the Core annotations of derivatives?"
As I mentioned during the meeting, the Lagrange notation is the usual one taught in K12 materials, so reasonable minds may expect that a Core concept name for derivatives would also be applicable to the Lagrange notation.
I'm sure people would agree that for $f^{(n)}$ hearing "the n-th derivative of f" is better than "f begin-superscript left parenthesis n right parenthesis end-superscript" or such. But we haven't resolved if that use is in Core or Open. One of the lists will need the generalized deriviative(<degree>,<function-name>,<bound-variables>)
formulation that Murray showcased. My example here could be intent="derivative(n,f)"
. But if that falls in the Open terrain, it could transfer to a new issue.
terse speak-aloud is specialized (for French and English it's the characters, I think), apparently not the case in Bulgarian?
It can be just the characters. My point during the meeting was that if a preposition was used it wouldn't be the same preposition used for fraction ("over"). As Neil agreed, English would similarly use "by". Hence the intent-free <mfrac>
behavior would be unfortunate for the Leibniz cases, and they would benefit from (always?) having an intent annotation on the <mfrac>
or <mrow>
(in the infix / case).
I think we agreed that derivatives like πβ²(π₯) can be spoken literally as "f prime of x". Ideally, the derivative πβ½βΏβΎ(π₯) should be spoken as "nth derivative of f of x". But I don't find such higher-order derivatives in my starting calculus textbooks. So maybe support for Lagrange higher-order derivatives isn't needed in core. Added speech for them in https://murrayiii.github.io/UnicodeMathML/playground/
It's also important to distinguish between speech verbosity and speech granularity. Verbosity can vary for "coarse-grained" granularity, that is, speech of whole expressions or equations. "Fine-grained" granularity is used for one-character-at-a-time speech which is needed to make math editing accessible. For this, the listener needs to know the actual symbols and where the insertion point is (e.g., 'end of numerator'). For the most part, intents aren't needed for fine-grained speech. But I have found them useful for distinguishing between what's displayed for differential d β (which might be π or d on screen) and the actual symbol. The listener should hear "differential d" in fine-grained speech, but just "d" in coarse grained speech. (Unless it's part of a derivative that's spoken more verbosely).
There are four common notations for differentiation:
(Df)(x)
$\dot{y}
$Terse pronunciations might be:
Verbose pronunciations might be:
There are also higher derivative forms of these (e.g., $d^2y/dx^2$ and $\ddot{y}$).
To me, the reasonable concept name is
first-derivative
. However, because these all have different terse forms, they shouldn't share the same concept name. Thoughts? Suggestions for names for first derivative forms and higher order derivatives?