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.

Comments URL: https://news.ycombinator.com/item?id=48839355

Points: 99

# Comments: 31

Comments URL: https://news.ycombinator.com/item?id=48307289

Points: 2

# Comments: 0

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

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?

  argv: Vec

  nums: Vec

  concat(Vec, Vec) -> Vec
  matmul(Mat, Mat) -> Mat
  head(Vec) -> (T, Vec)

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

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.

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