Live data from Hacker News

Render mathematical expressions in Markdown On GitHub

github.blog

71–80 of 114 posts

Re: Render mathematical expressions in Markdown On GitHub

#71

Earlier quoted context omitted.

In my opinion LaTeX is a poor fit for markdown, although it is the logical—and probably the only—choice. Markdown documents are supposed to be easy to read and quick to type. LaTeX is neither. When I include a matrix in my markdown document I want to type it something like: ## Example Matrix $$$ [a, b; c, d] $$$ Although I realize that we are probably stuck with LaTeX for the foreseeable future as the only way to typ…

I think you're right on all counts, especially on being stuck with LaTeX. What's your language? Any plans to build some sort of translator or other mechanism to allow high-quality rendering based on it?

Thanks for asking... I mentioned it earlier in this thread, and didn’t want to spam it unprompted. But it is called Mathup (https://runarberg.github.io/mathup/) and I purposely just translated to MathML and with the intention to leave rendering to a different library (e.g. MathJax; or the browser if you’re only targeting Firefox or Safari)

Re: Render mathematical expressions in Markdown On GitHub

#72
post #69

Earlier quoted context omitted.

> while no noticable slowdown for the user (it may even end up doing the "first paint" faster in the browser if GitHub are careful about their implementation). Have you visited math.stackexchange? Pop by their MathJax reference page[0], and observe how long all the mathematical notation takes to render fully —it takes at least six seconds on my recent notebook, plugged in. On my 2018 iPad Pro, it takes well over thir…

On my machine the first link loaded in under a second. On my mobile it was about 3 seconds, but it didn't feel especially sluggish. Even then, I'd say stackexchange has a somewhat inefficient implementation, in that they're trying to render everything in one shot. For example, I see no reason why they wouldn't just render the stuff that's in view first, and the rest is rendered incrementally as the user scrolls, or a…

> the first link loaded in under a second. On my mobile it was about 3 seconds

Did you wait for the typefaces to change to Computer Modern? On my smartphone, this took ages, and that is what I implied by 'fully loaded'; more complex maths is unreadable on some devices with only the native typefaces. Even a (relatively straightforward) cube root doesn't look clean[0].

MathJax has (from my observation) two 'levels' of rendering, where it uses the OS native typeface for a first pass, and then renders everything in Computer Modern for a uniform look (except on Apple devices, which somehow override this with STIX fonts).

Needless to say, the typeface change means that the dimensions of the maths content change, causing the rest of the website to reflow a second time. This second render takes the bulk of the time, and having a website's content unexpectedly jump around a long while after it has (apparently) loaded is not exactly user-friendly.

[0]: https://imgur.com/a/CrKqeI5

Re: Render mathematical expressions in Markdown On GitHub

#73
post #29

Earlier quoted context omitted.

For my blog (e.g. https://daniel.lawrence.lu/blog/y2021m09d08/ with tons of math), I render the math serverside using MathJax and serve them as SVG images (with alt text for the visually impaired). They get cached too which is nice especially since many symbols are duplicated. Seems fast enough for me.

Did you open-source the source code for trie DS visualization in your Aho-Corasick string matching algorithm blog?

Feel free to right click and view source and use it for whatever. I'll release it on Github with an MIT license when I get to my computer later...

Re: Render mathematical expressions in Markdown On GitHub

#74
post #56

Earlier quoted context omitted.

If I was building this feature, I'd also pick client side rendering, simply because at GitHub's scale, rendering on the server side will require a bunch of servers, which will need to be managed and looked after. By offloading the rendering to the client, you make use of the spare capacity that exists on most client machines today, with no noticable slowdown for the user (it may even end up doing the "first paint" fa…

The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9 . Browser JS engines are single threaded, so MathJax has to wait its turn behind more important scripts, and it gets worse with slower devices and networks. It's a contest of download vs execution time, which a 2KB pre-rendered image will always win. You're right on the money with the server costs though.

> Browser JS engines are single threaded

The JS interpreter is single threaded. But, you can offload the work to a web worker, that runs another instance of the interpreter in a separate thread.

Also for rendering LaTex it’s possible to optimize the rendering algorithm using WASM.

I’m not saying that MathJax does that, or it has good performance. But, there are options to optimize the client side rendering.

Re: Render mathematical expressions in Markdown On GitHub

#75

Earlier quoted context omitted.

Historically client-side rendering has been a big headache. Not sure if it's improved recently, but avid math bloggers and blog readers will remember the problems of the past decade.

As someone with no experience in the area, what have been the problems of the past decade?

I don't know why, but the rendering just wasn't that reliable. Equations failed to render too frequently.

Re: Render mathematical expressions in Markdown On GitHub

#76

Earlier quoted context omitted.

The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9 . Browser JS engines are single threaded, so MathJax has to wait its turn behind more important scripts, and it gets worse with slower devices and networks. It's a contest of download vs execution time, which a 2KB pre-rendered image will always win. You're right on the money with the server costs though.

> Browser JS engines are single threaded The JS interpreter is single threaded. But, you can offload the work to a web worker, that runs another instance of the interpreter in a separate thread. Also for rendering LaTex it’s possible to optimize the rendering algorithm using WASM. I’m not saying that MathJax does that, or it has good performance. But, there are options to optimize the client side rendering.

Workers lack document access and have to schedule updates with the main thread. That puts us back where we started (plus the overhead of starting the web worker).

I don't know enough about the state of WASM today to say the same. Circa 2018 I know that it lacked DOM manipulation.

(In some distant year I will figure out the incantation to avoid getting sniped when talking about this stuff. I think I rewrote that line 4 times.)

Re: Render mathematical expressions in Markdown On GitHub

#77
post #65

Is the renderer working for this page? Both 'renders' seem blurry on 2021 MBP in Chrome.

They’re screenshots.

But why can't they use their render feature for a doc that's literally written in Markdown?

Re: Render mathematical expressions in Markdown On GitHub

#78

Earlier quoted context omitted.

In my opinion LaTeX is a poor fit for markdown, although it is the logical—and probably the only—choice. Markdown documents are supposed to be easy to read and quick to type. LaTeX is neither. When I include a matrix in my markdown document I want to type it something like: ## Example Matrix $$$ [a, b; c, d] $$$ Although I realize that we are probably stuck with LaTeX for the foreseeable future as the only way to typ…

the matrix example is a good example of latex being too verbose for its markdown host. \underbrace and \begin{cases} are two others ones that seems antithetical to markdown. and maybe the fact that \left[ and \left( are not the default versions of [ and ( respectively. i'd be interested in collecting more if you can think of them.

I collected some in the doc page for mathup (link in cousin post). Although I’m not sure I tackled \underbrace sufficiently. E.g. This is how I explain up-arrow notion with a mathup expression:

    obrace(a\`↑↑`b = ubrace(a^a^⋰^a)._(b  "times")).^"" "up-arrow" notation ""
I don’t think you’ll be able to read this without knowing some of the syntax... which is a failure on my part as author. `obrace` and ubrace` are clear `.^` puts the following expression (a text that works the same way as backticks in markdown) over the preceding expression. `._` does the same but puts it under. and the backslash will make the thing surrounded by backticks (\`↑↑`) an operator. But this is a fairly complected expression. And my goal was never to make every expression look simple. A far more common expression would be easier:

    a^n = obrace(a xx a xx cdots xx a).^(n  "times")
which could also be written as:

    a^n = (a × a × ⋯ × a).^⏞.^(n  "times")
Regarding cases, in mathup could write:

    n! = { 1,      if n 
However the alignment won’t be perfect... I was always going to go back and fix that, but I never got around to do that.

Other improvements include, using white space smartly to group things together e.g. (This example also showcases using slash to denote fraction)

    a/b + c/d != a / b+c / d
Post reply on HN