clintonc

I wish this were organized according to suggested/logical reading order. For example, the paper introducing the attention mechanism probably ought to precede "attention is all you need".

My mind went to Java's checked exceptions -- not sure if anyone today believes that coloring is still a good idea.

<button type="button" class="download-hover" onclick="location.href='https://github.com/zellij-org/zellij/releases/latest/downloa...'"> linux download </button>

Screaming into the void, I guess, but PSA. Don't use buttons for links. In my case, I couldn't right-click and copy the URL, but there are a lot of other reasons not to do this.

I love this. Thank you.

Strange article. Why is Go the best language for agents instead of, say, Python? Here are the points the author seems to make:

---

# Author likes go

Ok, cool story bro...

# Go is compiled

Nice, but Python also has syntax and type checking -- I don't typically have any more luck generating more strictly typed code with agents.

# Go is simple

Sure. Python for a long time had a reputation as "pseudocode that runs", so the arguments about go being easy to read might be bias on the part of the author (see point 1).

# Go is opinionated

Sure. Python also has standards for formatting code, running tests (https://docs.python.org/3/library/unittest.html), and has no need for building binaries.

# Building cross-platform Go binaries is trivial

Is that a big deal if you don't need to build binaries at all?

# Agents know Go

Agents seem to know python as well...

---

Author seems to fall short of supporting the claim that Go is better than any other language by any margin, mostly relying on the biases they have that Go is a superior language in general than, say, Python. There are arguments to be made about compiled versus interpreted, for example, but if you don't accept that Go is the best language of them all for every purpose, the argument falls flat.

I have a Ph.D. in a field of mathematics in which complex numbers are fundamental, but I have a real philosophical problem with complex numbers. In particular, they arose historically as a tool for solving polynomial equations. Is this the shadow of something natural that we just couldn't see, or just a convenience?

As the "evidence" piles up, in further mathematics, physics, and the interactions of the two, I still never got to the point at the core where I thought complex numbers were a certain fundamental concept, or just a convenient tool for expressing and calculating a variety of things. It's more than just a coincidence, for sure, but the philosophical part of my mind is not at ease with it.

I doubt anyone could make a reply to this comment that would make me feel any better about it. Indeed, I believe real numbers to be completely natural, but far greater mathematicians than I found them objectionable only a hundred years ago, and demonstrated that mathematics is rich and nuanced even when you assume that they don't exist in the form we think of them today.

Curious to know what makes this "a proper VT100 implementation in the browser, not a JavaScript approximation of one" -- isn't Ghostty also an approximation, just implemented in a different language? Seems unnecessarily pejorative to me.

Whale oil and solar panels both being signs of high status.

The initial board position is certainly reachable (and reached in every game!), but there are only 20 legal moves available: the 16 legal pawn moves for White, and the 4 legal knight moves for White.

Then use 1/3 instead of 1/2 for a combined length of 2/3 -- the total length of the intervals can be as small as you like. This hints at the fact that any countable subset of the real numbers is Lebesgue measure zero.

Even using 1/2, the set that remains is nonempty due to the Cantor intersection theorem. The total length of the intervals is 1, which means that the remainder has no "interior" (i.e., contains no open interval), but the converse is not true: removing intervals whose lengths sum to less than one does not mean that the remainder will contain any interval. This is the consideration that allows you to create what are called "fat Cantor sets" -- the middle thirds Cantor set has Lebesgue measure zero, but by removing smaller intervals you can get other, homeomorphic sets that have positive measure.

There are a couple of strategies for understanding the real numbers. One is to write down a definition of real numbers, for example using rational numbers and Dedekind cuts, hoping that what you're describing is really what you mean. The other is to write down the properties of real numbers as you understand them as "axioms", and go from there. An important property of real numbers that always comes up (either as a consequence of Dedekind cuts or as an axiom itself) is the least upper bound property -- every set which has an upper bound has a least upper bound. That's what gives you the "completeness" of the real numbers, from which you can prove facts like the completeness of the real numbers (i.e., Cauchy sequences always converge), the Heine-Borel theorem (closed and bounded subsets of the reals are "compact", and vice-versa), and Cantor's intersection theorem (that the nested intersection of a sequence of non-empty compact sets is also compact).

The diagonalization argument is an intuitive tool, IMHO. It is great if it convinces you, but it's difficult to make rigorous in a way that everyone accepts due to the use of a decimal expansion for every real number. One way to avoid that is to prove a little fact: the union of a finite number of intervals can be written as the finite union of disjoint intervals, and that the total length of those intervals is at most the total length of the original intervals. (Prove it by induction.)

THEOREM: [0, 1] is uncountable. Proof: By way of contradiction, let f be the surjection that shows [0, 1] is countable. Let U_i be the interval of length 1/2*i centered on f(i). The union V_n = U_1 + U_2 + ... + U_n has combined length 1 - 1/2*n < 1, so it can't contain [0, 1]. Another way to state that is that K_n = [0, 1] - V_n is non-empty. K_n also compact, as it's closed (complement of V_n) and bounded (subset of [0, 1]). By Cantor's intersection theorem, there is some x in all K_n, which means it's in [0,1] but none of the U_i; in particular, it can't be f(i) for any i. That contradicts our assumption that f is surjective.

Through the right lens, this is precisely the idea of the diagonalization argument, with our intervals of length 2*-n (centered at points in the sequence) replacing intervals replacing intervals of length 10*-n (not centered at points in the sequence) implicit in the "diagonal" construction.

You can get that every integral domain is a field with fewer words by using a higher powered set theory result -- injections on finite sets are also surjections. The cancellation property says multiplication by any element is an injection, so it is also a surjection, i.e., 1 is in the range, so that gives you the multiplicative inverse.

It's a special move in chess called "castling". See https://en.m.wikipedia.org/wiki/Castling

From the page about dwm:

Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.

...sucks less than what? :) Simple is good, but simpler does not necessarily mean better.

Love the aesthetic, but I'm having trouble finding key information quickly.

- Is this a "traditional" RPN calculator?

- Does it have bonus features, like symbolic processing?

- Is it programmable?

I believe outcomes would be better if kids used RPN calculators when learning, and programmable is definitely a plus.

For me, it's a fit-for-purpose issue. Make is great when you're creating artifacts and want to rebuild based on changes. Just is a task runner, so while there's a notion of dependent tasks, there's no notion of dependent artifacts. If you're using a lot of .PHONY targets in a Makefile, you're mostly using it as a task runner -- it works, but it's not ergonomic.

I like that just will search upward for the nearest justfile, and run the command with its directory as the working directory (optional -- https://just.systems/man/en/attributes.html -- with fallback available -- https://just.systems/man/en/fallback-to-parent-justfiles.htm...). For example, I might use something like `just devserver` or `just testfe` to trigger commands, or `just upload` to push some assets -- these commands work from anywhere within the project.

My life wouldn't be that different if I just had to use Make (and I still use Make for some tasks), but I like having a language-agnostic, more ergonomic task runner.

Your example centered on a symbol which, if viewed as a subset of the plane, is not compact. I tried to argue that the set of symbols that you describe (ink of varying levels of intensity in the unit square) still is a compact set, even though the symbols themselves are no longer represented by compact sets.

I made a comment elsewhere on this thread that explains that symbols themselves being compact isn't so important, but that the set of descriptions of the symbols must be compact. For example, if the description of the symbol is not the symbol itself as a set, but a map f:[0,1]^2 -> [0,1] that describes the "intensity" of ink at each point, then the natural conclusion is that the description of a symbol must be upper semicontinuous, which makes the set of descriptions compact.

here if anywhere

:-D

We can play a lot of games with "what is a symbol", but compactness pervades many of the models that we use to describe reality. The crux of the argument is not necessarily that the symbols themselves are compact as sets, but that the *space of possible descriptions* is compact. In the article, the space of descriptions is (compact) subsets of a (compact) two-dimensional space, which (delightfully) is compact in the appropriate topology.

In your example, the symbols themselves could instead be modeled as a function f:[0,1]^2 -> [0,1] which are "upper semicontinuous", which when appropriately topologized is seen to be compact; in particular, every infinite sequence must have a subsequence that converges to another upper semicontinuous function.

Much of the fun here comes from the Tychonoff theorem, which says that arbitrary products of compact spaces is compact. Since the *measurement space* is compact, the topology of the domain is not as important, as long as the product topology on the function space is the appropriate one. (Mystically, it almost always is.)

It's like how there are so many things named after Euler. The joke goes that everything in math is named after the second person to discover it after Euler, but many things are named after him anyway.

Milnor is a titan in his fields, so any conjecture he has made would be called Milnor's conjecture.

This reads as a cynical description by someone who identifies as a "skilled pragmatist" (as I do, incidentally), but it doesn't seem to have a useful point of view. For example, "playing the system" and "making waves" have other names -- "driving initiatives" and "cross-team collaboration". They seem like "mushy" phrases because they are not well-defined sets of tasks like "deliver feature A" can become.

Are skilled pragmatists undervalued? Maybe, but this article doesn't do an good job of making me believe that.

The combinatorics of how the Mandelbrot set is put together is well-studied, and rather independent of MLC. The arrangement of the bulbs on the boundary of the "main cardiod" (which is where there is an attracting fixed point) is described here: https://en.wikipedia.org/wiki/Mandelbrot_set#Main_cardioid_a.... Generally, the patterns are given by something called Lavaur's Algorithm; see https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_com... for some explanation. Attachment points are always at the "root" of the Mandelbrot set, which is the cusp of the main cardioid.

A consequence of MLC is that the combinatorial picture given by Lavaur's algorithm and related analyses is "complete" -- all dynamical information is available from the combinatorial models.

MLC stands for "Mandelbrot Locally Connected". It's not obvious, but this is equivalent to the bulbs of the Mandelbrot set (the domains of parameters where almost all points get attracted toward periodic orbits) are dense in the Mandelbrot set. Everyone believes it to be true.

True.

I do, however, like having some of the amenities of a task runner without bringing in the "cruft" that's suited toward incremental builds. I like using Just (https://just.systems/) for those cases.

Don't give me strawman arguments and personal attacks,instead provide some valid counter arguments

You haven't provided an argument to counter. "Nobody drives the speed limit. Are people only interested in texting and fornication?"

Note: In this implementation, jumping off the board is only possible if the stack can reach exactly 1 row or column beyond the perimeter. But it seems to always be the case that it is possible to jump off the board when a stack is big enough. Please let Michael know if you encounter a scenario where a piece is stuck. This should not be allowed according to the rules of the game.

True. Suppose you moved from A to B, and your stack just became 8 tall. Then you must have jumped from one edge of the board to the other; if you jump back the way you came, you'll land on the "margin" outside of the board. Also, there are no other legal moves besides jumping onto the margin; in particular, you can never become 9 tall.

Repeat for smaller heights: If you are height N, but no other moves land on the board, then moving back in the direction the piece last came from will put it on the margin.

What's the advantage over using Flask's built-in support for async described here? https://flask.palletsprojects.com/en/2.1.x/async-await/

This is an honest question; I don't know much about python async yet.

$2.5M is a remarkably low percentage. If this means that 98% of the fine actually goes back to consumers, that's better than I've ever heard of from a class action lawsuit.

I came to the comments first. \o/

2:28 for Frixion pens.