ethanlipson

Why do nearly all the articles exploring the development of AI applied to math assume that capabilities won’t extend beyond theorem proving?

> other skills will matter more: choosing which terrain is worth exploring, steering fleets of airplanes, and explaining what they find to the rest of the world.

These all seem totally achievable by LLM agents, or at least, I don’t see an obvious reason why it wouldn’t be. 3blue1brown’s recent discussion on this subject was a bit better, but he spent the plurality of main body of the video assuming this scenario, devoting less time to the other possibilities. To me, it seems dangerous to build a math career on the foundation that AI won’t be able to explain math well in a few years, let alone a few months (which seems entirely plausible given the recent math progress).

To a first approximation I agree that it’s similar to industrialization. However there’s a key factor which distinguishes this case, and which makes the analogy less than perfect: there isn’t a profit motive in mathematics, so there was no push for this development from inside the field. Instead, the industrialization was entirely exogenous, from companies which do in fact have that profit motive and view math as a means to achieve it.

There might be a “proof motive” in math which one could argue will drive the full automation of theorem proving. But we must recognize that profit is more universally valuable (i.e. it has value outside the industry in which it was created), whereas proofs are only valuable inside the math community (at least the pure math proofs the labs have been publishing thus far).

Nvidia seems to be pushing Newton as a replacement for Isaac, so I think they're on the same page as you and me

TFA states “the less tau and pi, the better” and calls the radian-oriented functions “legacy”. I understand that a title like “Turns are Better than Radians” is intentionally inflammatory to get clicks, but I’d expect a more calibrated take in the article body. Phrasing like the above indicates the author doesn’t know what they’re talking about, even though I do agree turn-oriented functions would be useful.

I think the author is either being disingenuous or doesn’t understand the subject if they don’t honestly address the reason radians are used in the first place. I’m leaning towards the latter, because I can’t imagine someone having an ulterior motive for pushing for trig reform like this, lol. Radians really are the natural unit for trigonometry. With that said, I certainly agree that a lot of code would be simplified by using turns over radians, especially outside the context of numerical methods. I could see myself supporting the addition of sint(x) and cost(x) functions to the math standard library, where sint = “sine turns”.

While not a strict rule, Chesterton’s fence is a good heuristic: before we change something, we should first attempt to understand why it is the way it is.

How much money do you think they spent fine-tuning on pelican SVG generation?

In the words of my combinatorics professor, Dave Bayer:

> It is hard to shed prejudices about how code should look, even if learning to see clearly past convention is the only good reason to be a mathematician. I'm already quite sure how I will die: I'll read another article on Hacker News about a new programming language where I see nothing new, and I'll read that they included {}; to make C programmers comfortable. I'll have a massive stroke.

Whether we call it a distribution or not is really a matter of semantics.

The more interesting question is, do people actually want a hyper-opinionated Linux install? Based on the reactions to Omarchy that I've seen, the answer is obviously yes. Broadly, people seem ok with just not using some of the suggested software if the defaults get them most of the way there.

More generally, I would say that configuring one's own Linux installation is not in itself virtuous. It used to be a way to identify people who were "committed" to using it via gatekeeping. The OP says that Omarchy is just DHH "cashing in" on new inexperienced Linux users, but as long as we don't value customizing one's own installation just for the sake of customization (I certainly don't anymore!), why is this a problem?

I'm talking about cases where the array size is not known at compile time. For example, say the user passes in a list of numbers as command line arguments. Then we have

  argv: Vec<String, argc>

If I want to map these to ints, then I'd like a compile-time guarantee that the resulting array

  nums: Vec<Int, argc>

is the same length as argv. Lean and Idris can do this, but AFAIK no commonly used languages can. But unlike general dependent types, these are not hard to wrap one's head around and would save a lot of frustration, in my experience.

Futhark is really such a great idea. I'm not convinced that dependent types are worth the cognitive overhead in general, but it's definitely worth it to include the length as part of the type information for dynamic arrays, e.g.:

  concat(Vec<T, n>, Vec<T, m>) -> Vec<T, n+m>
  matmul(Mat<T, n, m>, Mat<T, m, l>) -> Mat<T, n, l>
  head(Vec<T, n+1>) -> (T, Vec<T, n>)

This would have saved me so much headache debugging CUDA kernels and numpy!! I wish it were a first-class feature in those frameworks, and even general-purpose languages, but alas.