Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typst's Math Mode Problem

laurmaedje.github.io

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Typst's Math Mode Problem

#31

Post by fweimer »

MayeulC wrote: post #20
fweimer wrote: post #10

Earlier quoted context omitted.

I find https://github.com/typst/typst/pull/7072#issuecomment-338580... more enlightening about what's going on. Specifically the difference between these three: 1/2(x + y) 1/x(x + y) 1/2^x(x + y) With a programming language background, that's just odd to reconcile. If 1/2 is treated as a rational integer literal, it's possible to explain the difference between the first two. (And apparently this difference is wildly…

It's also a cultural thing I suppose, as I would personally understand all these expressions having just one as the numerator and the rest below. It may be related to the fact that "mixed numbers" were never part of my curriculum (Wikipedia¹ says they are more common in non-metric regions). Or it may be just me. In any case, I find this notation ambiguous, so I would not expect a compiler to resolve it correctly. Edi…

> Edit: also, I would rather write (x + y)/2 if I wanted half the sum, that seems much more logical to me than moving non-integer factors around.

Based on what I recall, there's a bit of an aversion towards writing / or ÷ for division (or explicitly written multiplication). And $\frac{1}{2}(x+y)$ is more readable in inline text than $\frac{x+y}{2}$.

Re: Typst's Math Mode Problem

#32

Post by lou1306 »

trueismywork wrote: post #21
ajkjk wrote: post #19

It feels absurd to have this occur in the parser, as if you can somehow account for all the cases via guessing what people I mean. You absolutely must have a grouping operation like {} at least available as a fallback. I feel like this is a lesson people keep learning over and over across programming languages: don't let your syntax try to infer the intended meaning of what was typed, just do something simple and pre…

I complained about this before and people dismissed me as an old timer. I did doubt myself as well to be honest. Its bittersweet to be correct.

I hate recurse to authority, but after a markup slash programming language has been written by Don Knuth and a macro system for it has been developed by Leslie Lamport, maybe one should take some notes so as to why things were done in a certain way?

Re: Typst's Math Mode Problem

#34

Post by MayeulC »

fweimer wrote: post #31
MayeulC wrote: post #20

Earlier quoted context omitted.

It's also a cultural thing I suppose, as I would personally understand all these expressions having just one as the numerator and the rest below. It may be related to the fact that "mixed numbers" were never part of my curriculum (Wikipedia¹ says they are more common in non-metric regions). Or it may be just me. In any case, I find this notation ambiguous, so I would not expect a compiler to resolve it correctly. Edi…

> Edit: also, I would rather write (x + y)/2 if I wanted half the sum, that seems much more logical to me than moving non-integer factors around. Based on what I recall, there's a bit of an aversion towards writing / or ÷ for division (or explicitly written multiplication). And $\frac{1}{2}(x+y)$ is more readable in inline text than $\frac{x+y}{2}$.

I agree, though I wish you had specified in what context that aversion was.

To give a specific example, I can cite units in the metric system, often written as kg.s⁻².J⁻¹ instead of the more ambiguous kg/s²/J; which could technically be read as kg/(s²/J), giving kg.J.s⁻¹.

Re: Typst's Math Mode Problem

#35

Post by jraph »

ajkjk wrote: post #19

It feels absurd to have this occur in the parser, as if you can somehow account for all the cases via guessing what people I mean. You absolutely must have a grouping operation like {} at least available as a fallback. I feel like this is a lesson people keep learning over and over across programming languages: don't let your syntax try to infer the intended meaning of what was typed, just do something simple and pre…

> Personally I think the "best" workaround for this is to decouple the text representation and the representation the editing happens in. Allow people to type e^abs(x) and then the editor translates that into e^{abs(x)} while letting you edit it as an exponential, but if you're working on the underlying text file then you have to write e^{abs(x)}. For that matters, you can just have the editor represent it as a literal superscript.

I'm pretty sure that's how LyX does it, possibly others as well.

Re: Typst's Math Mode Problem

#36

Post by abdullahkhalids »

ajkjk wrote: post #19

It feels absurd to have this occur in the parser, as if you can somehow account for all the cases via guessing what people I mean. You absolutely must have a grouping operation like {} at least available as a fallback. I feel like this is a lesson people keep learning over and over across programming languages: don't let your syntax try to infer the intended meaning of what was typed, just do something simple and pre…

Typst has made some basic choices, which as someone who typsets a lot of math, makes it a no go.

- The use of space character to also act as the escape character (latex use backslash) [1]. Not only does it cause confusion, I have to now escape everything $F=ma$ become $ F = m a $ in typst. Complex math equations will be complex no matter what - why make simple equations harder to type to make it slightly easier to type complex ones.

- The lack of these grouping brackets (latex uses curly parenthesis).

What I want from my typesetting language is "typsetting completeness". While there might be sane defaults, I want to be able to control every decision made by the typesetter by escaping and grouping things as needed. If the language doesn't have these features, by definition, it is not complete.

[1] Latex also has to use space to act as ending delimiters. $\alpha x$ is correct and $\alpha\beta$ is correct, but $\alphax$ is not. But the solution to this is to allow $αx$ which some flavors of tex do.

Re: Typst's Math Mode Problem

#37

Post by tonyarkles »

fwlr wrote: post #29
andrepd wrote: post #8

I really don't see the problem with the current notation. I find that is very simple and intuitive: function calls bind tightly, use a space to change that. f_i(x) vs f_i (x) 1/x(a+b) vs 1/x (a+b) ab vs a b So simple. Being too "smart" invariably leads to more headaches and confusion than just having a simple, consistent rule.

From quickly messing around in the playground, it seems (in math mode) Typst treats multiple spaces identical to single spaces. A simple, consistent, flexible, and probably-not-majorly-breaking-old-documents rule would be “anything with no spaces has higher precedence / tighter binding than anything with one space, anything with one space has higher precedence / tighter binding than anything with two spaces”, etc, an…

I agree with you conceptually, and am also laughing a bit thinking about how many people get angry about significant whitespace in Python and how much deeper down that rabbit hole "operator precedence changes based on whitespace" this proposal is :D

Re: Typst's Math Mode Problem

#38

Post by runarberg »

abdullahkhalids wrote: post #36
ajkjk wrote: post #19

It feels absurd to have this occur in the parser, as if you can somehow account for all the cases via guessing what people I mean. You absolutely must have a grouping operation like {} at least available as a fallback. I feel like this is a lesson people keep learning over and over across programming languages: don't let your syntax try to infer the intended meaning of what was typed, just do something simple and pre…

Typst has made some basic choices, which as someone who typsets a lot of math, makes it a no go. - The use of space character to also act as the escape character (latex use backslash) [1]. Not only does it cause confusion, I have to now escape everything $F=ma$ become $ F = m a $ in typst. Complex math equations will be complex no matter what - why make simple equations harder to type to make it slightly easier to ty…

As an author of a different math typesetting tool (mathup) I explicitly made the choice of making simple expressions simple to type at the expense of making complex equations less intuitive. But I still have the same problem as OP, where simple expressions break because the intuitive behavior is the opposite of what my parser does.

AsciiMath (what my tool was inspired by) tries to be smart about this by parsing a/f(x) differently from a/x(f) and it looks like typst is making the same choose. I on the other hand opted to rather stay consistent. My reasoning is that the tool is fast enough, and I rarely (actually never) type my math expressions outside of an interactive experience where I can’t view the rendered result as I type, so I can spot my mistakes immediately (usually fixed by adding a space, or surrounding something with parens).

Re: Typst's Math Mode Problem

#39

Post by runarberg »

eviks wrote: post #26

>pi(1 + 2) is a function call or just pi multiplied by three. another case for using proper notation π with some autosubstitution rules so that you can resolve the ambiguity immediately while typing (if pi is converted into π you backspace and let it stay pi as a function) But #functions also seems like a good option for readability

MathML recommends using the invisible operators for invisible times or function application (&InvisibleIimes; [U+2062] and ⁡ [U+2061] respectively) to differentiate the two.

Re: Typst's Math Mode Problem

#40

Post by eviks »

runarberg wrote: post #39
eviks wrote: post #26

>pi(1 + 2) is a function call or just pi multiplied by three. another case for using proper notation π with some autosubstitution rules so that you can resolve the ambiguity immediately while typing (if pi is converted into π you backspace and let it stay pi as a function) But #functions also seems like a good option for readability

MathML recommends using the invisible operators for invisible times or function application (&InvisibleIimes; [U+2062] and ⁡ [U+2061] respectively) to differentiate the two.

Unfortunately, they're... invisible. Though they can still be highlighted in an editor, so also helpful
Post reply on HN