ethanlipson

hace 16 díasdiscuss

[dead]

el mes pasadodiscuss

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

hace 2 mesesdiscuss

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.

ethanlipson

hace 2 mesesdiscuss

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?

ethanlipson

hace 2 mesesdiscuss

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.

ethanlipson

hace 2 mesesdiscuss

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.

ethanlipson

hace 2 mesesdiscuss

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/

ethanlipson

hace 8 mesesdiscuss

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.

ethanlipson

hace 8 mesesdiscuss

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

ethanlipson

Submissions

MIRA: Multiplayer Interactive World Models Trained on Rocket League

Dr. Z's Opinions

comments