(Opinions needed) Likely upcoming changes to math mode precedence

General
29

I’m not a mathematician so I could be wrong, but I support option C or D for the following reasons:

  1. Symbols of functions, like f, can be standalone. I mean, when we say there is a function, we don’t have to say f(x). In this case, f is math symbol. And f(x) is a kind of operation to map x to something else via function f. In most cases, attachments are symbols, not operations. Because of this, when we write $f_i(x)$, we would not expect i(x) to be something attached, unless i is a user-defined “programming” function (stated as below). In this case, treating the i(x) part as the attachment seems to be strange.

  2. Some special functions, like “sin”, they are predefined symbols, although it could be rare to see “sin”, “cos”, etc., alone.

  3. However, abs(x) represents “|x|” in math. Thus, “abs” itself is not a symbol; instead, “abs(x)” the whole thing is. Because abs is a programming function, not a mathematical symbol or operation. A standalone abs does not make mathematical sense.

  4. For other user-defined functions, I think they would probably prefer keep the whole thing together. As an example, I defined a function to show conditional expectation, like

     #let Exp(x, ..args) = $E lr((#x mid(|) #args.pos().join(",")))$

    When I write $e^Exp(x,u)$, I definitely want the part like $E(x|u)$ to show at the corner, instead of a “E” at the corner but “(x|u)” not.

    Another example is the Imaginary number. If we define a function

     #let Im(a,b) = $#a + #b i$

    then I also expect $e^Im(1,2)$ to show something like “e^(1+2i)”, not “e^1 + 2i”.

Overall, I think it would be better to act differently for different components. If the attached component is a “programming” function, like abs and user-defined functions, treat the whole thing as the attachment. For math.op and normal math symbols, don’t show them like function calls.

4 Likes