xworld21

I appreciate the sentiment, especially after the escalation of the last few weeks. But I am hoping this story can become an example of why mathematicians are still very much needed and LLMs are still severely lacking when it comes to displacing scientists. Conway's conjecture has no application whatsoever, even within pure maths, and the only point in pursuing it is what you can learn in the process, and whether you can make something beautiful. LLMs are consistently unable to do the latter (and yes, some mathematicians are also not very good at it... this is an old topic of discussion, just amplified by current events). To me it feels like the technology is still where it was in 2015 when DeepDream images came out: increasingly good at pattern matching, but still a lot more like dreaming than thinking. So our job is still there somewhere.

The problem is rather how quickly we can change our ways of working to make sure the training and hiring pipeline does not collapse. That's the disastrous scenario, for both the individuals affected and the discipline, that we must avert somehow. I wish we had an easy answer to that. I certainly don't. But I like to think that at least engaging with the public in a constructive way will have a net positive effect.

Vincenzo (Mantova) here: yes, I have been reading bits and pieces of the proof and I can say for sure that the method is sound, at least for the first half (power series with real exponents). I haven't even tried reading the part that mentions the Cantor-Bendixson rank yet, although given how the rest went, I'd be really surprised if there's a problem there.

As with most interesting proofs, the number of core ideas is actually small, I'd say two for the real exponents, and presumably a third idea for lifting up to omnific integers. I have been redoing the real exponents part of the proof going on the ideas only, and with a few smarter choices, I am converging on something very short. And I mean very short, which is amazing. I didn't think the answer would be this close: it 'just' needs looking at the problem from the right angle, and also make a fairly bold guess at the outcome.

Dan's current proof is of course much longer. Between the fossilized ideas that Dan mentions in the post and the formalisation of previous results, there's a lot of cruft that inflates the proof but does not really help understanding what is going on. Luckily the word 'derivation' pops up early, otherwise it would have been very challenging to wade through the lemmas to find the important points.

> On a related note: is mathML more accessible than an AI generated text of how a human would read the mathematical or chemical formula?

Yes, screen readers would typically allow you to navigate the formulas in ways that are more sophisticated than text (not to mention the issues with translating to Braille, which I don't claim to understand, at all). In fact alternative text is a poor substitute for structured information about the formula, which is what you get with MathML.

Plus, the MathML + screen reader combo is deterministic and debuggable, as opposed to OCR'ing an image.

> There is katex-rs[0] that outputs html and mathML. I'd assume the two could work together and the mathML would be fed to whatever the screen reader receives instead of the image?

Maybe! You are parsing the input twice, but it could be a pragmatic solution. I don't know myself how native apps are supposed to expose MathML to screen readers (or if it is even possible without an embedded browser!).

True, my knee jerk reaction came from seeing this run in the browser... but that does not change the question. RaTeX advertises itself as a renderer for native apps, but how are those apps supposed to implement accessible controls? Does RaTeX offer anything towards that?

I suppose somebody has to ask (and most likely complain) about this: what does RaTeX do for accessibility? I gather that it produces images. I checked the demo, and there's not even an alternative text or an ARIA label, so this seems completely invisible to anybody relying on a screen reader. This is quite a step backwards compared to modern LaTeX, which can now tag equations with MathML within the PDF, or using MathJax, or any other serious tool targeting HTML, like pandoc or LaTeXML.

Is accessibility anywhere on the roadmap for RaTeX?

Indeed, LaTeXML (the software used by arXiv) converts LaTeX to a semantic XML document which is turned to HTML using primarily XSLT!

I believe dginev's Docker image https://github.com/dginev/ar5ivist is very close to what runs on arXiv and can be run locally. It uses a recent LaTeXML snapshot from September.

I posted this in another thread

> Even the official Adobe's example of reflowing you posted before is quite bad:

> https://helpx.adobe.com/uk/acrobat/using/reading-pdfs-reflow...

> The reflowed PDF is just stacking all text and removing all non-text visual cues. For example, pairs of name/role are separated by whitespace in the PDF, but after reflowing they are undisguishable from each other (who would be the senior VP, Sunny or Daniel?). In HTML, reflowing would preserve semantically relevant whitespace out of the box.

Even after properly tagging your PDF and using Acrobat Reader to reflow the text, you cannot achieve this level of flexibility: https://forallx.openlogicproject.org/html/

Note how Richard's book adapts to any screen size, can change fonts and color schemes, system settings such as 'high contrast' will affect the rendering of the page, and you could even use browser extensions to restyle the page to e.g. use a more dyslexic friendly font of your choice.

This kind of functionality is not afforded by Adobe Reader. Even the official Adobe's example of reflowing that was posted in another thread is quite bad: https://helpx.adobe.com/uk/acrobat/using/reading-pdfs-reflow... The reflowed PDF is just stacking all text and removing all non-text visual cues. For example, pairs of name/role are separated by whitespace in the PDF, but after reflowing they are undisguishable from each other (who would be the senior VP, Sunny or Daniel?). In HTML, reflowing would preserve semantically relevant whitespace out of the box.

> Compile to DVI then use dvipng

or dvisvgm, which will produce scalable images. However, images are even worse than PDF in terms of accessibility, which is what the article is talking about.

> Just like a lecturer won't suddenly switch to a German accent when saying words like "schadenfreude" or names like "Friedrich Nietzsche"

Is there a middle ground? Whenever I check my content with a screen reader, uncommon foreign names are often mispronounced in ways that are sometimes almost irrecognisable. Even my name comes out wrong, although it would be understandable (typically, the stress ends up on the wrong syllable).

I agree, and the article talks about working with LaTeX and converting directly to HTML. This is more about replacing the final PDF with HTML.

The article talks about converting LaTeX to HTML, which is feasible today, if only buggy and fragile. This is the textbook the author talks about, which is written in LaTeX (but compiled with LaTeXML instead of pdflatex): https://forallx.openlogicproject.org/html/

The accessibility and reflowability of HTML content, not to mention the ability to customize color schemes, fonts, line spacing, and similar are not possible with PDF, even using Adobe software. Even using the latest PDF 2.0 standard, you are ultimately expected to convert it to HTML if you need all that flexibility (such as via https://ngpdf.com/).

The developers seem aware and "are working on a solution" https://consentomatic.au.dk/

> A 50-page PDF loads a lot faster and shows a lot smoother than an HTML of equal textual length.

Very true! Although they are now comparable, if you rely on the browser native MathML instead of MathJax/LaTeX.

(You can test this on long arXiv HTML papers, e.g. https://ar5iv.labs.arxiv.org/html/1710.07304 is more than 60 pages as PDF. Mind you, the ar5iv default CSS is not great. I would use Latin Modern for formulas, at the very least.)

> I've never seen any modern tools that turn TeX into multifile HTML (one per section).

I believe all of them can do it out of the box now. I know for sure that LaTeXML, tex4ht and lwarp can split by chapter or section.

The tagging work is still highly experimental. A major missing element is equation tagging: for now, you need to produce an 'associated MathML' file externally, for instance using LaTeXML. Even then, PDF readers do not support the MathML tags yet! If anything, I am sure that the LaTeX3 team would appreciate you posting minimal examples of mistagged PDFs.

If you want to produce accessible documents from LaTeX, you should convert to HTML. ATs such as screen readers just work miles better than with PDFs, and given the resources put in developing browsers compared to PDF readers, I don't think this will change any time soon. Luckily conversion from LaTeX to HTML is very feasible today, as proved by arXiv. (Shameless plug: I maintain BookML specifically to help lecturers with the LaTeX to HTML work)

Cool!

Would you consider adding a web font with the proper OpenType features to render the MathML content? The Igalia work in Chrome is quite decent when the font is good, but for now it needs to be set via CSS (presumably Chrome does not feel like bundling a math font just yet).

Some nice demos are at https://fred-wang.github.io/MathFonts/mozilla_mathml_test/ (with Latin Modern, the TeX Gyre's, FiraMath – other fonts are still glitchy).

Funnily enough, the traditional formal definition of product is due to Peano and it would say 5x3=5+5+5: https://en.m.wikipedia.org/wiki/Peano_axioms#Multiplication