The proof proceeds by a modification of the Duffin–Schaeffer argument, together with the two-constant theorem of Nevanlinna (and some standard estimates of harmonic measures on rectangles) to deal with the effect of the localization. (As a side note, this latter argument was provided to me by ChatGPT, as I was not previously aware of the Nevanlinna two-constant theorem.)
Which I find funny in a way: I'm sure that almost no one here understands the article, grasps the significance of this problem in mathematics, or can meaningfully comment on the difficulty of solving it. But we'll still have opinions because the article mentions a popular tool some of us like, some of us dislike, and some are ambivalent about.
It would be surreal if a carpentry forum was regularly abuzz about mountaineering because climbers use a hammer-shaped tool.
Nevanlinna theory isn’t that obscure (in the sense of mathematics, I suppose) but it is very difficult (for me, probably less so for Tao) when working to have the whole of 21st century analysis in your head at once and see what could be applied where. I can see how an LLM would be quicker than a human at recognizing a context where a theorem from an apparently unrelated subfield could be applied.
From a few older posts, I estimate that there are at least 10 mathematicians here, some doing math research and some doing other stuff. This is bleeding edge math, so probably only 100 persons in the word are working in something close enough to understand this now. [I guess I can understand it if I take a month [1] to study this and drop everything else.] I worked in harmonic analysis [2], but this looks more related to maximals that is a topic that I tried to avoid. I'm not sure about the areas of the other mathematicians here.
Anyway, there are a lot of topics in the discussion in HN and many times someone can give some insight. Sometimes it's about compilers and there are a few users that know about that. Sometimes it's about rockets and there are a few users that know about that. Sometimes it's about steel alloys and there are a few users that know about that. ... Not everyone here is a programmer.
I'm using very little AI, but my wife has been using it a lot. We both agree that it's at the level of a Gold medal in the IMO, that means that it can kick our ass hard. Anyway, sometimes the AI hallucinates and sometimes makes stupid error, so it's necessary to verify the output.
[1] It looks short, so perhaps a week is enough, but I feel I'm being too optimistic. Let's say a month just to be safe.
[2] Protip: If you see a circle, take the Fourier Transform and cross your fingers. You can't believe how many problems it solves. If it's useful, add me as a co-author.
We've always been bikeshedders. For example, back in Slashdot days, some company would decide to migrate something from Windows to Linux. Immediately the debate became whether they should have gone with Debian or SuSE instead of Red Hat.
offtopic, but it's interesting how large of a discrepancy there is between the length of your comment and how much time i'd have to spend explaining background info to a non-programmer to get them to understand why this is funny
I have used "--" as a lazy-man's emdash for decades at this point. Once I heard that people started assuming text that uses emdashes was written by an LLM I got worried that people were going to think that I'm an LLM, but then I realized the LLMs use the real unicode emdash character, while I just use two regular ASCII-zone hyphens. Whew.
(Also I just learned that ASCII 0x2d/unicode U+002D is more properly called a "hyphen" [well, "HYPHEN-MINUS"], not a "dash".)
In theory, yes, endash would be "--" and emdash would be "---", but oof, the three hyphens looks like way too much in normal text. So I've always used "--".
For what it's worth, I've been doing basically this with magit for years now, sometimes with the two-commit setup but usually just using the index plus top commit instead. It's not as slick, though, so this is on my list of things to try out when I give jj a spin eventually.
`c F` in the magit menu squashes staged changes directly into a commit in the log, and `c e` amends (which is to say squashing into the tip). So in this case I'd hit `s` to stage, and either `c e` or `c F j C-c C-c` (fixup, move one item down to get to HEAD^, confirm) — both of which are practically atomic operations for me at this point.
Same for me originally (years past) CLI git, then magit and more recently lazygit. Identical workflows across all 3 tools, with only progressively fewer keystrokes.
I have been working on a 100% vibe-coded magit-style jujitsu porcelain for neovim. I cannot emphasize "vibe-coded" enough -- I have not read a single line of code here, nor do I know much about neovim development in general. All that said, it's been working pretty well for me the last couple weeks!
The problem is TUIs. Or at least the assumption you're only supposed to use a TUI. There are plaintext ways to invoke things but the advertised Claude/Codex experience is a TUI. You can't pipe the contents because it's not next - it's instructions to draw to the terminal.
<humor>TUIs are the new podcast! With everyone asking you to invoke tools via a TUI, there was nobody left to write actual tools.</humor>
reply