tel

Probably some kind of agricultural taxation scheme from 2000 bce or so.

Or Fisher in the 1930s with data driven linear didcriminants.

A huge amount of math unlocked the minute mathematicians started taking complex numbers seriously. Ideally they would be an earlier discovery, I agree!

I've been spending the last couple months working on a Markdown-like lightweight document format. (Short pitch, it's like Markdown but with natural extension points built in and far less subtlety).

A huge part of my goal is to write a "spec" of the format. I want it to be good enough that users can legitimately file bugs against my primary implementation for not following the spec: it is the source of truth about the language.

So, of course, I find it really interesting to discuss the grey space of "shrug, maybe this is correct". This whole process has been driving me to (a) make the language itself resilient and permissive so that it has _some_ answer for nearly all documents and (b) to constrain the output of the system such that it throws away as much information as possible, enabling us to make claims about semantics more confidently.

I don't know if I'm going to succeed at all my goals. This is sort of a small project and definitely far simpler than, say, a web browser. At the same time, it's very hard to narrow in on what it is, really, that I want such a spec to say.

To be fair, that wasn’t my issue. I don’t find it annoying. I find it misleading and nigh fraudulent.

I think it’s because it’s reasonable to believe that the human author had no meaningful contribution. If he’d written “by Claude with direction from me” then I’d feel more comfortable. If he’d hand written in his own voice a methods section that laid out exactly how he prompted the LLM then I’d have no trouble digesting.

But to take ownership over words and thought in this way reads as nearly fraudulent to me.

I think the point was that Claude’s output can be somewhat easily and compellingly measured using this technique and its kind of massive (and human attributed).

I appreciate the connection to artists guiding their teams. I think that's a good analogy.

At the same time, when Koons or Chihuly or Cummins sign their work I do have that expectation that they guided the piece in a meaningful and material way or that the people who built it did it in such a way that owes lineage and authorization to the style Koons/Chihuly/Cummins developed. If I asked one of them about their work and it was clear that they had become so disconnected from it that they couldn't be seen as the authority on it, that they'd delegated that away, then I'd also feel them signing it had a mark of dishonesty about it.

To that end, I genuinely don't know Mr. Gomila's engagement here. Worse, it, to my ear, very clearly is written in a style that's extremely reminiscent of LLMs. In that way, it directly invokes that feeling of inauthenticity when he claims authorship.

This reminds me of academic writing there there's sometimes a convention in author lists that the first author(s) did more of the work and the last author(s) were the PIs and guides. This anchors the work amidst all the authors, at least loosely. I understand that if I want to ask a question about the details of the procedure I can reach out to the first author and if I'm trying to understand the larger research objectives of the lab I can investigate the last author.

Personally, I think I'd feel more comfortable with this piece if it were attributed in that style.

Or, again, if this is genuinely work done in the majority by Mr. Gomila and the writing feels LLM-derived for some other reason then it's merely an unfortunate side-effect of this writing register.

I'm not able to judge this for content, but it feels frustrating to read something so obviously Claude-authored as being written "by" Jude Gomila. It's interesting to see the (presumed correct) reduction in this bound and this presentation is pretty compelling. I learned a bit about the Polymath 15 project from this post and I enjoyed that a lot.

That said, I have no idea what contribution may have been done by Mr. Gomila or not. I don't know if I can ask him for more details. Even if he wrote the whole thing (and either has deeply internalized Claude's voice or had it edited and rewritten by an agent) it's difficult to believe that he's the sort of expert I'd expect of someone who had actually done all this work.

This is basically the same feeling I have about vibe code contributors.

Increasingly, I've begun to think of LLMs as sources of really interesting random objects: large pieces of "reasonable thinking" conditioned on a task. It's not that these are correct, in general, but instead they're a concentrated form of random search where that "randomness" is very likely to follow plausible, human patterns.

You can toss it at a task with a suitable machine for transforming that raw material into action and it'll rattle through and sample "plausible human behavior" at that endpoint.

There are more clever ways to use it, but a general tool here is to upgrade any sort of stochastic search to use this new form of random sampling. It'll be way more efficient, properly conditioned, because it just won't visit implausible things nearly as often as competing random sources.

In short, simplify the design to make it more reasonable for multiple implementations to agree while also adding intentional extensibility points and a governance model that allows for dialects to form without fracturing the community.

Markdown is really interesting. For most readers and most writers it's dead simple and you just get the idea from a few examples or reading a short description. In practice, it's dozens of dialects (though 3 related ones dominate) and dozens more implementations. It's hard to write new, compatible implementations, so they tend to fracture.

(This may be less true with LLMs nowadays, but it might also be worse.)

Often, someone wants to write a Markdown variant because they wish it supported some new extension to help it mesh with the use case and tool they are envisioning. Each one of these is a new fracture.

My goal is a simple specification that's easy to reimplement that eliminates years of cruft and subtle complexity. I'm designing it to be simple and obvious to extend and building a governance model so that extensions can live together, grow, maybe even become mainstream all without ever breaking compatibility.

I'm working on an improved Markdown that offers a simplified language, clear hooks for extensibility, and a governance model to let it grow over time.

An assert statement requires that you specifically come up with a test case. Lean lets you verify for all possible cases. Infinity is not a problem.

It's similar to a type system in that regard. The same difference could be applied there (comparing a Python type assert). Types, however, generally only cover checks similar to "the shape of the data is X".

Lean is different in that its language for expressing properties is wide enough to express anything you can imagine. The bottleneck becomes accurately stating properties you'd like to enforce and, subsequently, discovering proofs of whether or not they're true.

Without having any opinion on whether or not the Bun team was meaningfully fuzzing their codebase... Andrew's claim was not about whether or not they were, it was noting that the story was different between what they claimed in conversation and what they stated in this article.

It's also a language of distancing from personal experience and honesty.

Not saying you're wrong. Professionalism is an important tool for maintaining professional relationships. Lack of professionalism is dangerous to the point where it is reasonable for certain kinds of societies to begin to shun people who don't engage with it.

And, at the same time, a certain amount of emotional honesty can be really important to share, too. And that includes some amount of judgement and criticism.

It sounds like Zig's relationship with Bun is over. While Anthropic/Jason/Bun did not write a personal narrative about the end of that relationship, they absolutely were the initiators and could not have done this in a more aggressive way. It feels to me to be approximately the equivalent of moving out in secret and serving the divorce documents through your lawyer.

I think you've got it. You go in each day and work on things and talk with people working on things. There are multiple opportunities to share weekly, one or two are pretty regular and the rest are self-organized. Maybe you learn about something new and dive in, maybe you come up with a project and share it with others.

I think the beating heart is that everyone is there with some passion to learn and build and you're encouraged to do so collaboratively. It's surprising, I feel, how rare it is to have a community of folks who are all learning together and not afraid to dive in and figure things out. Recurse Center is a chance to spend 6 or 12 weeks building and then living in a place like that.

I'm working on an easy-to-embed typed language called Ekto. I am taking a lot of inspiration from Koka and aiming to support full multi-shot delimited continuations all while keeping the virtual machine deeply predictable from the host side.

I'm also rebuilding an integrated task/knowledge/publication system I'd previously built atop Gemini's Gemtext format. While I loved the simplicity, I've discovered that there are lots of burrs in that design, especially on the publication side, which I'd be able to lift by using a more fully featured document format like Djot.

I was asking questions about compiler techniques. Then when I got annoyed I started asking about experimental design. Both were very frustrating experiences once I started realizing how limited its responses were.

Though yeah the edgelord-y style faded after I criticized it a couple times.

All my usage of Grok for technical topics shows it regularly deeply misunderstanding things and just parroting back my question in fancy language. It’s the only frontier model I get this impression of. That makes it super annoying when it tries to market itself as good at engineering tasks when it seems (to me) to be much worse at them.

I think, yes, with greater splat density—and, critically, more and better inputs to train on, others have stated that these performances were captured with 56 RealSense D455fs—then splats will more accurately estimate light at more angles and distances. I think it's likely that during capture they had to make some choices about lighting and bake those in, so you might still run into issues matching lighting to your shots, but still.

https://www.realsenseai.com/products/real-sense-depth-camera...

That said, I don't think splats:voxels as pixels:vector graphics. Maybe a closer analogy would be pixels:vectors is the same as voxels:3d mesh modeling. You might imagine a sophisticated animated character being created and then animated using motion capture techniques.

But notice where these things fall apart, too. SVG shines when it's not just estimating the true form, but literally is it (fonts, simplified graphics made from simple strokes). If you try to estimate a photo using SVG it tends to get messy. Similar problems arise when reconstructing a 3d mesh from real-world data.

I agree that splats are a bit like pixels, though. They're samples of color and light in 3d (2d) space. They represent the source more faithfully when they're more densely sampled.

The difference is that a splat is sampled irregularly, just where it's needed within the scene. That makes it more efficient at representing most useful 3d scenes (i.e., ones where there are a few subjects and objects in mostly empty space). It just uses data where that data has an impact.

Gaussian splatting is a way to record 3-dimensional video. You capture a scene from many angles simultaneously and then combine all of those into a single representation. Ideally, that representation is good enough that you can then, post-production, simulate camera angles you didn't originally record.

For example, the camera orbits around the performers in this music video are difficult to imagine in real space. Even if you could pull it off using robotic motion control arms, it would require that the entire choreography is fixed in place before filming. This video clearly takes advantage of being able to direct whatever camera motion the artist wanted in the 3d virtual space of the final composed scene.

To do this, the representation needs to estimate the radiance field, i.e. the amount and color of light visible at every point in your 3d volume, viewed from every angle. It's not possible to do this at high resolution by breaking that space up into voxels, those scale badly, O(n^3). You could attempt to guess at some mesh geometry and paint textures on to it compatible with the camera views, but that's difficult to automate.

Gaussian splatting estimates these radiance fields by assuming that the radiance is build from millions of fuzzy, colored balls positioned, stretched, and rotated in space. These are the Gaussian splats.

Once you have that representation, constructing a novel camera angle is as simple as positioning and angling your virtual camera and then recording the colors and positions of all the splats that are visible.

It turns out that this approach is pretty amenable to techniques similar to modern deep learning. You basically train the positions/shapes/rotations of the splats via gradient descent. It's mostly been explored in research labs but lately production-oriented tools have been built for popular 3d motion graphics tools like Houdini, making it more available.

Definitely not common! Nice to hear I'm not alone either.

And yeah, I agree. Practically, it's the thing that annoys me the most day-to-day. I've mostly got wrapping set up to handle it now, but it remains a little finicky.

I've recently begun replacing Markdown with Gemini's .gmi/gemtext format. It is Markdown with fewer features. I appreciate the simplicity and it's tremendously easy for custom tools to parse.

It has no inline formatting, only 3 levels of ATX headers (without trailing #s), one level of bullet points using only asterisk and not dash to delimit, does not merge touching non-whitespace lines (thus expecting one line per paragraph), and supports only triple-backtick fenced preformatted text areas that just flip on and off.

Maybe the biggest change is that links are necessarily listed on their own line, proceeded by a `=>` and optionally followed by alt-text.

My gemtext parser is maybe 70 lines and it is arguably 95% of what one needs from Markdown.

SDFs still scale by geometry complexity, though. It costs instructions to evaluate each SDF component. You could still use something like BvH (or Matt Keeter’s interval arithmetic trick) to speed things up.

Genuine question, how does SPIR-V compare with CUDA? Why is SPIR-V in a trench coat less desirable? What is it about Metal that makes it SPIR-V in a trench coat (assuming that's what you meant)?

At the same time, if you want to use Claude to read the source and narrate how it works to you that’s trivial to do as a user.

If you're familiar with Zorn's Lemma, the construction is just to order bases by inclusion and to consider chains created by noting that there must be an independent dimension and adding it inductively. You can upper bound each of these chains by unioning the members of the chain (which preserves linear independence). By Zorn's Lemma that means there is a maximal linearly independent system and if an element existed outside of that system's span it would contradict that maximality.

Yeah, that's correct. You also often see it as having that for any method `X -> T<Y>` there's a corresponding method `T<X> -> T<Y>`. Or you can have that for any two arrows `X -> T<Y>` and `Y -> T<Z>` there's a composed arrow `X -> T<Z>`. All are equivalent.

Every monad is also an applicative and liftA2 does/is the same thing as liftM2. The only reason they both exist was due to Monad being popularized in Haskell earlier than Applicative and thus not having it as a superclass until the Functor-Applicative-Monad Proposal in Haskell 2014. It was obviously correct, but a major breaking change that also got pork barreled a bit and so took a while to land.

Monad tutorials are on the rise again.

Let's start with function composition. We know that for any two types A and B we can consider functions from A to B, written A -> B. We can also compose them, the heart of sequentiality. If f: A -> B and g: B -> C then we might write (f;g) or (g . f) as two different, equivalent syntaxes for doing one thing and then the other, f and then g.

I'll posit this is an extremely fundamental idea of "sequence". Sure something like [a, b, c] is also a sequence, but (f;g) really shows us the idea of piping, of one operation following the first. This is because of how composition is only defined for things with compatible input and output types. It's a little implicit promise that we're feeding the output of f into g, not just putting them side-by-side on the shelf to admire.

Anyway, we characterize composition in two ways. First, we want to be clear that composition only cares about the order that the pipes are plugged together, not how you assemble them. Specifically, for three functions, f: A->B, g: B->C, h: C->D, (f;g);h = f;(g;h). The parentheses don't matter.

Second, we know that for any type A there's the "do nothing" identity function id_A: A->A. This doesn't have to exist, but it does and it's useful. It helps us characterize composition again by saying that f;id = id;f = f. If you're playing along by metaphor to lists, id is the empty list.

Together, composition and identity and the rules of associativity (parentheses don't matter) and how we can omit identity really serve to show what the idea of "sequences of pipes" mean. This is a super popular structure (technically, a category) and whenever you see it you can get a large intuition that some kind of sequencing might be happening.

Now, let's consider a slightly different sort of function. Given any type types, what about the functions A -> F B for some fixed other type F. F here exists to somehow "modulate" B, annotate it with additional meaning. Having a value of F B is kind of like having a value of type B, but maybe seen through some kind of lens.

Presumably, we care about that particular sort of lens and you can go look up dozens of useful choices of F later, but for now we can just focus on how functions A -> F B sort of still look like little machines that we might want to pipe together. Maybe we'd like there to be composition and identity here as well.

It should be obvious that we can't use identity or composition from normal function spaces. They don't type-check (id_A: A -> A, not A -> F A) and they don't semantically make sense (we don't offhand have a way to get Bs out of an F B, which would be the obvious way to "pipe" the result onward in composition).

But let's say that for some type constructors F, they did make sense. We'd have for any type A a function pure_A: A -> F A as well as a kind of composition such that f: A -> F B and g: B -> F C become f >=> g : A -> F C. These operations might only exist for some kinds of F, but whenever they do exist we'd again capture this very primal form of sequencing that we had with functions above.

We'd again capture the idea of little A -> F B machines which can be plugged into one another as long as their input and output types align and built into larger and larger sequences of piped machines. It's a very pleasant kind of structure, easy to work with.

And those F which support these operations (and follow the associativity and identity rules) are exactly the things we call monads. They're type constructors which allow for sequential piping very similar to how we can compose normal functions.

The more constrained your theory is, the fewer models you have of it and also the more structure you can exploit.

Monads, I think, offer enough structure in that we can exploit things like monad composition (as fraught as it is), monadic do/for syntax, and abstracting out "traversals" (over data structures most concretely, but also other sorts of traversals) with monadic accumulators.

There's at least one other practical advantage as well, that of "chunking".

A chess master is more capable of quickly memorizing realistic board states than an amateur (and equally good at memorizing randomized board states). When we have a grasp of relevant, powerful structures underlying our world, we can "chunk" along them to reason more quickly. People familiar with monads often can hand-wave a set of unknowns in a problem by recognizing it to be a monad-shaped problem that can be independently solved later.