ethanlipson

I agree that being technically gifted has been a great way to make boatloads of cash in the past few decades, and that this correlates with being good at math. But I don’t see why this implies that enjoying math means someone is more money-minded than others. If anything, the students in pure math departments are intentionally forgoing the potential cash conferred by their technical abilities in favor of the academic pursuit. In anticipation of a reply observing that math PhDs regularly go into quant, I counter that quant programs reach out to interview students in many other fields, and more to the point, spending half a decade studying algebraic number theory is surely not even close to an efficient way to build wealth. In response to your second point: even if mathematicians desired wealth more than other professionals, how does this demonstrate the existence of some kind of profit motive in math?

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).

Why would this be a good heuristic?

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.

For models as complex as these I'm not confident we can apply arguments from first principles; we could just as easily argue that type information is helpful, from first principles. What is much more useful is empirical evidence, and AutoCodeBench [1] found that LLMs are most proficient in Elixir (dynamic) followed by Kotlin (static), with Rust and PHP at the bottom. So it would seem like, as of publication, typing style doesn't really matter!

[1] https://autocodebench.github.io/

For a general function F, finding the points (x, y) with F(x, y) = 0 has no closed-form solution. The entire field of mathematical optimization is largely dedicated to finding solutions to F(x, y) = 0, in one form or another.

When F has a special structure (say, low-order polynomial), we can actually find the exact solutions. More general structure (e.g. convexity, differentiability) doesn't give us the exact solution, but it lets use use clever numerical algorithms to find them. There are techniques we can use when F has little to no structure, known as "black box" methods, and they work particularly well when we have few variables. In the case of "fuzzy graphs", there are only two variables, so this software takes the approach of computing F(x, y) for every pixel on the screen. In general this doesn't work due to the curse of dimensionality, but it creates good visualizations in low dimensions :)

To answer your question directly, yes we can use differential geometry to speed up optimization. As an example, you've probably heard of gradient descent. Preconditioned gradient descent leverages the geometry of the surface to speed up convergence. In the language of differential geometry, if we're optimizing f(x), then x is "contravariant" but grad(f) is "covariant", so technically we can't just add grad(f) to x since they have different types. We first have to multiply grad(f) by a rank-2 tensor (the "preconditioner") that encodes the local curvature of f around x. This technique is used by the Adam optimizer, with the assumption that the preconditioner is diagonal.

Neat, but I think it's deceptive for the website to claim this is a "new type of graphing" [1]. The fuzzy graph of F(x, y) = 0 is simply a 3D plot of z = |F(x, y)|, where z is displayed using color. In other words, F(x, y) is a constraint and z shows us how strongly the constraint is violated. Then the graph given by F(x, y) = 0 is a slice of the 3D graph. If you're claiming that you've discovered visualizing 3D graphs using color, you're about 50 years too late.

[1] https://gods.art/fuzzy_graphs.html