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

11–20 of 57 posts

Re: Typst's Math Mode Problem

#11

Post by runarberg »

In mathup[1] I handle this by allowing authors to strategically place space around groups they want to operate on:

    e^ x-1
I also implemented invisible operators (plus, times, function application, and separator) with special operators (`.+`, `.*`, `.$`, and `.,` respectively) so authors can be explicit about their intentions (and output more accessible expressions)

    f_i .$ (x)
    a / b.*(1 - x)
    sum_ X_ i.,j
1: https://mathup.xyz/

Re: Typst's Math Mode Problem

#12

Post by davorak »

nightskyblue wrote: post #7

When I found out that option B was already merged [1] I got very excited because the current behavior is still very unintuitive to me and one of the few areas where I prefer the behavior from Latex. Unfortunately, the changes were reverted shortly after because they discovered deeper issues with the new old design [2]. As far as I can see, there hasn't been any further progress on this, sadly. [1] https://github.com/…

The newest pull request is:

https://github.com/typst/typst/pull/7137

from what I can tell. The commits look two days old so work looks on going.

I do not understand the current set of preferences laid out in:

https://github.com/typst/typst/pull/7072#issuecomment-338580...

I do not understand 8, 9 'my preference' column and why they would make the similar syntax render differently.

Re: Typst's Math Mode Problem

#13

Post by laurmaedje »

weinzierl wrote: post #6

I had my gripes with LaTeX but the backslash in front of every macro was never one of them. I think it helps not only machine parsing but very much my human visual parsing. BTW one related trap in LaTeX is if a macro without parameters removes the trailing space from the output. The article mentions this in passing but does not say what Typst's solution is. Do Typst functions always require parentheses? I'm also conf…

While not really related to the math topic, let me answer this:

- You can add an arbitrary number of trailing `[..]` blocks and they are just trailing arguments. So 2 & 3 are really the same.

- 3 & 4 are different because argument lists may _never_ have a space before them in Typst. you can also not write `calc.min (1, 2)`

The reason why the space may not be added is that you can write

    #for x in range(5) [
        Value is #x
    ]
And `range(5) [..]` therefore needs to be different from `range(5)[..]`. This aligns with normal formatting conventions and I haven't seen this become a problem in practice.

Re: Typst's Math Mode Problem

#14

Post by laurmaedje »

davorak wrote: post #12
nightskyblue wrote: post #7

When I found out that option B was already merged [1] I got very excited because the current behavior is still very unintuitive to me and one of the few areas where I prefer the behavior from Latex. Unfortunately, the changes were reverted shortly after because they discovered deeper issues with the new old design [2]. As far as I can see, there hasn't been any further progress on this, sadly. [1] https://github.com/…

The newest pull request is: https://github.com/typst/typst/pull/7137 from what I can tell. The commits look two days old so work looks on going. I do not understand the current set of preferences laid out in: https://github.com/typst/typst/pull/7072#issuecomment-338580... I do not understand 8, 9 'my preference' column and why they would make the similar syntax render differently.

(Author of the post and issue comment here.)

The preferences there were honestly rather ad-hoc w.r.t to the pull request and the approach the pull request took. And (as the author laid out), the PR was a rather ad-hoc solution for a problem we discovered literally one night before Typst 0.14 was supposed to be released.

The design thoughts there were a bit half-baked, which is why we've closed the PR and reverted the original change, to get more time to properly reconsider things.

The math syntax has seen little change since Typst's initial release (except for the infamous precedence change in 0.3 that triggered all this) and just has some quirks that haven't been properly ironed out yet. However, it will remain a focus now and we want to give it a proper cleanup.

Re: Typst's Math Mode Problem

#17

Post by zygentoma »

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.

Exactly this!

It is just plain simpler than the original TeX/LaTeX notation.

Re: Typst's Math Mode Problem

#18

Post by sureglymop »

I like typst but in all honesty I was a bit disappointed when I saw that they didn't have a backwards compatible math mode. Looking at all the shortcomings of latex, I wouldn't say the math notation is part of it.

And since probably many people are very familiar with it, I would have liked for them to just keep that part.

Re: Typst's Math Mode Problem

#19

Post by ajkjk »

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 predictable.

So (b) seems like the only sane choice, but having the grouping operation being e^(abs(x)) is also crazy. You need something like TeX's e^{abs(x)}.

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.

(My hunch is that this is generally much-needed across languages: let the editor do some of the parsing work. I think there's much to be gained by separating the two, because you can keep the parser of the actual language simple while still getting all your editing-efficiency improvements out of the editor).

Re: Typst's Math Mode Problem

#20

Post by MayeulC »

fweimer wrote: post #10
nightskyblue wrote: post #7

When I found out that option B was already merged [1] I got very excited because the current behavior is still very unintuitive to me and one of the few areas where I prefer the behavior from Latex. Unfortunately, the changes were reverted shortly after because they discovered deeper issues with the new old design [2]. As far as I can see, there hasn't been any further progress on this, sadly. [1] https://github.com/…

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.

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.

¹ https://en.wikipedia.org/wiki/Fraction#Mixed_numbers

Post reply on HN