Equations

[jayvdb]

While looking for optimal solutions for #3, I noticed most of them are caused by the decision to use [] for subscript in equations, along with ^ for superscript.

I am not aware of [] being a common approach for subscript in equations, while ^ is a very common approach for superscript.

_ is the more common syntax for subscript, as in LaTeX, and AsciiMath, etc.

But the only common (and github flavour) markdown solution is <sup> and <sub>. Problem 479 is currently using that approach.

We also have problems using $$ or $ with Latex : problems 431, 450, 463, 471, and 473.

A quick rundown of the options:

• Use <sup> and <sub>. Simple and widely supported. Ugly to read for complex equations. And then do we also use HTML tables for complex equations, etc? That isnt a good path to follow.
• Use Unicode subscript and superscript. grep -P "[\x80-\xFF]" README.md already has 603 lines, so we're definitely not plain ascii any more. I was initially quite keen on this approach. It looks very nice in linux text editors, reasonable in linux browsers (but far from perfect), but then I found the glyphs were missing on my slightly old Samsung tablet (https://en.wikipedia.org/wiki/Talk:Unicode_subscripts_and_superscripts#Browser_support) , so we cant expect it to work on cheaper smartphones. My unicode solution for Fix square brackets that are parsed as links #3 can be seen at https://github.com/jayvdb/PocketEuler/tree/gh-3-unicode (e.g. problem 149, 165, 186, etc)
• Give up on README.md rendering equations correctly on Github.com, and switch to GitHub Pages as the intended renderer. Then we can use maruku or similar. The Github.com view would still degrade to a readable syntax, but it wont always be pretty or easy to understand. I dont see this as a huge problem, as the use of [] is not very readible IMO, nor is it common. This is what happens for the problems currently using $/$$ .
• Store each equation in a separate file, or an embedded comment in the MD using <!--- ---> for pandoc support, and render them to an SVG, PNG, etc. to be stored in the repo and included by the MD. (i.e. a bit like https://hopstat.wordpress.com/2015/07/31/rendering-latex-math-equations-in-github-markdown/ , but I think that can be improved upon)
• Use an online renderer, like http://mathurl.com/ , e.g. ![](http://mathurl.com/render.cgi?%5Czeta%28s%29%20%3D%20%5Csum_%7Bn%3D1%7D%5E%5Cinfty%20%5Cfrac%7B1%7D%7Bn%5Es%7D%5Cnocache) is , or http://www.sciweavers.org/free-online-latex-equation-editor also works sometimes, but then doesnt - strange. While those URLs can be decoded, they are not readable, so again a HTML comment would be appropriate for people reading the README.md as-is.

Any other options?

[jayvdb]

Here is a prototype of using hidden equations rendered to gif https://github.com/jayvdb/PocketEuler/tree/render-latex#problem-431 (https://github.com/jayvdb/PocketEuler/tree/render-latex). For that equation, we should probably use unicode, but it is just a simple example. I'll try some more complicated equations tomorrow. And if the idea works, I could package it up as a JS node remark plugin.
Using svg didnt work in Github, and using svg -> png created a very large image.
The attribute name data-expr comes from http://willdrevo.com/latex-equation-rendering-in-javascript-with-jekyll-and-katex/ . It could be named anything.

[jayvdb]

I've completed 431, and added problems 328, 332 and 335 (these replace existing images with generated images).

https://github.com/jayvdb/PocketEuler/commits/render-latex

• problem 328 replaced 994 and 1049 byte gifs with 898 and 739 byte gifs
• problem 332 replaced 964 bytes with 585 bytes
• problem 335 replaced 1055 bytes with 871 bytes

The newly rendered images are no as pretty inline, as the height isnt optimised for the text. But the layout is reasonable, and more importantly the MD now contains the equation in a precise standard format. I should be able to improve the inline display, but IMO that isnt a serious problem - let me know if you disagree.

Is the syntax ok? Adding class="equation" is redundant, so I think I might remove that to make the source more readable. The renderer will need to be improved slightly, but I'd rather a complex renderer than unreadable MD.

[jayvdb]

Interesting ![](http://mathurl.com/render.cgi?%5Czeta%28s%29%20%3D%20%5Csum_%7Bn%3D1%7D%5E%5Cinfty%20%5Cfrac%7B1%7D%7Bn%5Es%7D%5Cnocache) was showing a nicely rendered image, but now shows an image with "your domain is not authorized to use mathtex on this server" in red.

[imsky]

the notation was from the original document by Keen.

i would strongly prefer we use ASCII/basic UTF8 for equations, and failing that, with LaTeX notation. images in general are a poor format for equations.

[jayvdb]

...basic UTF8...

Most equations need sup or sub support, which isnt complete in UTF8, and doesnt work on some modern devices. Sup 1-3 is all that work on my tab. I can ask around on wikipedia technical forums to see if this problem has been reported by other mobile users.

We could put a note at the top saying "PocketEuler use these glyphs: ..... If any are missing here please install font.... / PocketEuler is incompatible with your system"

Are you implying that <sup> and <sub> are undesirable?

and failing that, with LaTeX notation.

LaTeX literally in the Github output, enclosed in $?

Many other markdown tools would then do the right thing. I can build a list of major md tools which will fail to render the latex.

And my funky <img> prototype with hidden LaTeX isnt an acceptable workaround?
(I cool with that; imo PE solvers should learn to read literal LaTeX; that is the real world for maths)

[imsky]

Are you implying that <sup> and <sub> are undesirable?

I think they're fine, but they fail when copy/pasting.

LaTeX literally in the Github output, enclosed in $?

Sure - we can always fall back to pure text, which would work in any LaTeX editor.

And my funky prototype with hidden LaTeX isnt an acceptable workaround?

It's acceptable, but I'm slightly biased against using images generated remotely. Even if we can keep raw LaTeX in the Markdown and generate a HTML document with the right equation display, that would be an improvement over embedding images.

[jayvdb]

I could use <img alt="$eq$" ... which will make it assessible to visually impaired, and should work in any md w/ latex editor.
Then provide a regex or tool to strip the img tags so the resulting md has literal latex embedded, for use with pandoc etc.

But the opposite also works for me. Literal latex in the source md, and generate a md with img tags and the img files, or generate pure html versions of the equations.

[imsky]

The first approach works for me as long as a caption is supplied with text that a user can select.

The second approach seems to be the best, however readers will need a preamble to explain the notation.

[jayvdb]

checking browser support for first option: not good so far https://bugs.chromium.org/p/chromium/issues/detail?id=625388

https://bugzilla.mozilla.org/show_bug.cgi?id=768291

[imsky]

captions could just be text under the image.

[jayvdb]

Yea, thats a good idea for block equations, but I cant see that working for equations embedded in prose.
We could move some of the inline equations to be a new block under the prose, by slightly revising the prose.
Im guessing that wont work in all cases.

[imsky]

that's why i think Keen originally used basic ASCII for equations - they fit most of the use cases and require a minimal amount of explanation.

i'm OK with any solution as long as it's accessible and doesn't require remote servers.

[jayvdb]

A little more playing ... even with images disabled, most browsers make it difficult to access the img title, except with developer tools. Even Firefox extensions dont make this easy. And Chrome doesnt have developer tools on Android, or the ability to install extensions.

So I'm giving up renderring img files, and agree we should use literal latex enclosed in $ whenever there are subscript in the equation. And we can use/fix/write a user-script to apply MathJax or similar to the latex, for anyone who needs help parsing the latex in their brain. Again user-scripts are not available for Chrome on Android

[jayvdb]

@georgenetu , I see you've been adding lots of problems, and have one more to add. Do you have any thoughts on this before we lock in one approach?

[ghost]

Hi @jayvdb . It's been 7 months since I submitted #8 , so I "can't" have any thoughts until I get at least some feedback on it.

[jayvdb]

Hi @georgenetu , I've created #47 about one aspect of your merged additions, and I view this issue as also being feedback on your additions (at least Problem 479 is mentioned).

Your additions have a different style from previous additions, but that is mostly because the repository doesnt have any style recommendations, and hasnt had any linting, and probably also because the style of the HTML for Project Euler has been revised also. There is no right answer; just tradeoffs.

Other than Problem 479, the equations on all your other problems look pretty good as they are simple equations. For Problem 479, the use of sup & sub means information is lost during copy and paste. If we want to avoid that, we would need to switch the equation from using sup & sub to being a LaTeX equations. Then the problem is it is harder to read for people not already familiar with LaTeX equation syntax. Do you disagree with that type of change?

[jayvdb]

We now have a new problem with _ in equations becoming italics in problems 186 , 230, 422, 444, and 468 .

To avoid this, we may need to use a workaround like 29\lower0.5ex\hbox{x} instead of 29_x to achieve subscript in LaTeX and not cause the markdown to render as italics on Github and likely any other tool which doesnt handle $..$ as special. Youch.

[imsky]

why not just encode those as inline code blocks with backticks?

[jayvdb]

Ya, backticks would be better than 29\lower0.5ex\hbox{x}.

However it is only occurring in a few cases where _ are included in the equation, while many other cases of _ are not converted to italics.

I'd like to find what is causing this, as that may give us other workarounds.