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

Math on GitHub: The Good, the Bad and the Ugly

nschloe.github.io

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Math on GitHub: The Good, the Bad and the Ugly

#31

Post by runarberg »

forgotpwd16 wrote: post #28
runarberg wrote: post #19

The author fails to mention MathML as an alternative choice. The options aren’t just MathJax and KaTeX, but also raw MathML. MathML gives you extremely fast rendering, more font choices, copy-paste, a11y, etc. out of the box. The only downside is that Chrome is lagging behind in implementation, for that they could use MathJaX as a polyfill—as MathJax understands and is able to transform MathML—and allow Safari and Fi…

It isn't mentioned because because they aren't really the same thing. MathML is a web native math markup language and being XML is meant to be written by machines rather humans[^0]. TeX is a markup language that MathJax and KaTeX render to a web suitable format but meant to be written by humans[^0]. Both MathJax and KaTeX have support for rendering TeX to MathML. [^0]: Compare Pythagorean theorem written in MathML an…

Nobody writes the first example by hand[^1]. They write it in TeX (or some other easy to write dialect, or use a graphic WYSIWYG editor) and then use a tool to translate it to MathML.

What I’m advocating here is that GitHub translates TeX to MathML on their servers and serve us the MathML, as opposed to leaving the TeX as is and ship a JavaScript library to render it after it reaches our browsers. Chrome users won’t see a difference as they don’t support MathML, so they need MathJax as a polyfill. But there is a world of difference for us Firefox and Safari users.

Another benefit is that you could allow us to include the pure MathML (by hand or authored by some other tool) if we preferred that.

^1: and if they did write it by hand it would be written as

    
      
        a
        2
      
      +
      
        b
        2
      
      =
      
        c
        2

Re: Math on GitHub: The Good, the Bad and the Ugly

#32

Post by patrick451 »

> The reason why I’m so excited about this feature is that, in combination with version control and the issues/discussions capabilities in GitHub, I can see tectonic changes in how we’re publishing science. At last, science can really reap the benefits of a connected internet by moving away from static PDFs to living, breathing repositories which render like PDFs and provide a central place where one can actually talk about the article. – And fix bugs!

I'm skeptical of this take. Gitlab has had math rendering support for quite a while now, so this is hardly novel and doesn't seem to have resulted in the utopia the author is hoping for.

Re: Math on GitHub: The Good, the Bad and the Ugly

#33

Post by Beldin »

patrick451 wrote: post #32

> The reason why I’m so excited about this feature is that, in combination with version control and the issues/discussions capabilities in GitHub, I can see tectonic changes in how we’re publishing science. At last, science can really reap the benefits of a connected internet by moving away from static PDFs to living, breathing repositories which render like PDFs and provide a central place where one can actually tal…

I had the same feeling for a different reason: I don't think this reduces friction enough compared to sharing LaTeX files (on github or overleaf), which we can already do. So I don't think this will usher in a new era.

I realise this could very well become the next "dropbox comment" - and I'll be happy to be proven wrong.

Re: Math on GitHub: The Good, the Bad and the Ugly

#34

Post by macintux »

bla3 wrote: post #12

> Its main advantage over MathJax is that it isn’t dead. Check out the repo activity on the two projects: I know this is a common view, but this is such a strange mindset to me. Unless you add scope, a project is eventually just mostly done. It's not that MathJax has zero commits, it just has fewer. That _in itself_ isn't a bad sign to me. It could just mean it's a mature project.

Per jaltekruse it’s inaccurate; work has moved repos.

https://news.ycombinator.com/item?id=31457631

I do tend to think that any web technology that isn’t changing is dying. Browser, HTML, are admittedly both much more stable than they used to be, but the world keeps moving.

(Edit: fixed spelling of @jaltekruse)

Re: Math on GitHub: The Good, the Bad and the Ugly

#35

Post by IshKebab »

hprotagonist wrote: post #9
ly wrote: post #7

Earlier quoted context omitted.

I prefer the $ $ way, as it makes it possible to do inline equations, while keeping the source easily readable.

you can do both, the normal markdown way: `$a$` squared is `$a^2$`, which is good to know for the pythagorean theorem: ```equation a^2+b^2\eq c^2 ```

That doesn't work because then how do you display $a$ as literal inline code?

Re: Math on GitHub: The Good, the Bad and the Ugly

#36

Post by patrick451 »

Beldin wrote: post #33
patrick451 wrote: post #32

> The reason why I’m so excited about this feature is that, in combination with version control and the issues/discussions capabilities in GitHub, I can see tectonic changes in how we’re publishing science. At last, science can really reap the benefits of a connected internet by moving away from static PDFs to living, breathing repositories which render like PDFs and provide a central place where one can actually tal…

I had the same feeling for a different reason: I don't think this reduces friction enough compared to sharing LaTeX files (on github or overleaf), which we can already do. So I don't think this will usher in a new era. I realise this could very well become the next "dropbox comment" - and I'll be happy to be proven wrong.

It would be cool if they would just render entire latex manuscripts that are part of the repo. It sort of sucks that you need to duplicate what you wrote a paper submission into markdown to get github to render it.

Re: Math on GitHub: The Good, the Bad and the Ugly

#37

Post by runarberg »

IshKebab wrote: post #35
hprotagonist wrote: post #9

Earlier quoted context omitted.

you can do both, the normal markdown way: `$a$` squared is `$a^2$`, which is good to know for the pythagorean theorem: ```equation a^2+b^2\eq c^2 ```

That doesn't work because then how do you display $a$ as literal inline code?

What about:

    Inline code is ` $a$ ` automatically trimmed
But I think $`a+b`$ makes more sense (or even $$a+b$$; I mean this is markdown after all, not LaTeX).

Re: Math on GitHub: The Good, the Bad and the Ugly

#38

Post by IshKebab »

throwaway981572 wrote: post #24

I’m very happy they went with simple $..$ and $$…..$$ This is much more natural for anyone doing math or science and also makes it easy to copy and paste math from elsewhere It’s better that the parser works harder than to force an inconvenient syntax on the user.

The problem with heuristic parsers is that you can't learn the rules, so the only way to use it now is with live preview.

Re: Math on GitHub: The Good, the Bad and the Ugly

#39

Post by nvrspyx »

auggierose wrote: post #25
runarberg wrote: post #21

Earlier quoted context omitted.

The pick of $ and $$ as delimiters seems rushed, to be frank. Although I’m not a big fan of mixing LaTeX in Markdown, I understand that choice (alternatively you could go with ascii-math like syntax which mixes way better with Markdown IMO). But $ and $$ makes not a lot of sense other then LaTeX does it this way. It would have been easy e.g. to use $$ for inline math and $$$ + newline or ```math for block, and that w…

Given that the main point of using LaTeX in Markdown is familiarity of users, using $ and $$ is actually the ONLY proper choice. But yeah, it leads to problems, which is why I would not use Markdown in the first place, but some Markdown inspired format which mixes better with $ and $$.

This is why I prefer AsciiDoc. It's consistent because there's only one implementation, it's less ambiguous, and more predictable. Although it takes a bit longer to remember all the syntax, it's not difficult, especially if you're only going to use the same subset of features that markdown supports since it supports most of the markdown syntax as well. I also much prefer the flexibility with tables compared to markdown. I just wish there were more parsers/converters other than the main ruby one and the transpiled JS one, although I know there's work being done on other language implementations.

As an example for math/equations, inline math is stem:[sqrt(4)], which defaults to AciiMath, but can be changed with a page attribute. To specify inline, LaTeX is latexmath:[\sqrt(2)] and AciiMath is asciimath:[sqrt(2)].

For blocks (which you can replace stem with either latexmath or asciimath to specify),

[stem] ++++ sqrt(2) ++++

Re: Math on GitHub: The Good, the Bad and the Ugly

#40

Post by forgotpwd16 »

runarberg wrote: post #31
forgotpwd16 wrote: post #28

Earlier quoted context omitted.

It isn't mentioned because because they aren't really the same thing. MathML is a web native math markup language and being XML is meant to be written by machines rather humans[^0]. TeX is a markup language that MathJax and KaTeX render to a web suitable format but meant to be written by humans[^0]. Both MathJax and KaTeX have support for rendering TeX to MathML. [^0]: Compare Pythagorean theorem written in MathML an…

Nobody writes the first example by hand[^1]. They write it in TeX (or some other easy to write dialect, or use a graphic WYSIWYG editor) and then use a tool to translate it to MathML. What I’m advocating here is that GitHub translates TeX to MathML on their servers and serve us the MathML, as opposed to leaving the TeX as is and ship a JavaScript library to render it after it reaches our browsers. Chrome users won’t…

>What I’m advocating here is that GitHub translates TeX to MathML on their servers and serve us the MathML

I see. What confused me was the "options aren’t just MathJax and KaTeX, but also raw MathML" since those tools can be used server-side and they output some HTML or MathML or images. MathJax moreover besides TeX also takes MathML and AsciiMath input.

>Another benefit is that you could allow us to include the pure MathML

I guess they went with what most people work with since rendering TeX in Markdown complements their Jupyter notebook rendering.

>and if they did write it by hand it would be written as

Maybe. I copied my example from MDN docs git repo.

Post reply on HN