-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core concepts: how should the multiple forms of differentiation be handled? #473
Comments
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 |
This is a brainstorming comment from me. 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: 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 So, back to the differentiation cases Neil mentions, one could imagine generating
If that offered significant benefit over the bare 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 Incidentally, there's a variant of Euler, 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 |
I've long been under the impression that if 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: I think the issue here is trying to separate the concept from the semantics. For example, if 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? |
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
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.
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 |
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 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 Edit: added a link to the alternative notations page on function composition. |
I think only the 1st & last speech templates are needed here:
|
In the Math WG meeting today, we agreed to the following:
An example of the usage of intent for the derivative:
|
For the record: |
I have a question on whether the first arg to The wiki definition has such an example:
I think there are two other possible variations just for Leibniz notation: Q: Is this case meant to have intent
[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 |
Indeed, it needs to be expression, more generally. Regarding your second point, perhaps all these variant notations want the more explicit 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:
By "needs", I mean won't be spoken well without
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 @dginev wrote:
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
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?
The first is the same as our original example, where Bruce suggested that maybe all the arguments are optional. I don't think that works. They might be empty/blank, but 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 There's quite a bit of confusion in the discussion of various variants (misunderstanding of notations or misunderstanding of comments about notation?) The notation 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. |
I think it's the usual workaround - we need a wrapping ExampleFor
|
𝑑𝑓/𝑑𝑥 (𝑥) 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 there is some brief text on that use at the Notation for differentiation wiki page.
And I get about a hundred more hits when switching the Edit: Changing my comment to match some newly gathered data.
(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:
|
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
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 |
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:
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?The text was updated successfully, but these errors were encountered: