amluto

As a little public resource announcement:

    <script type="module" blocking="render"
    src="https://cdn.jsdelivr.net/npm/justif@0.5.0/dist/auto.js"
    ></script>

I’m fairly confident that the blog post is trying to say something like this:

Given a polynomial function from C^n to C^n, the following statements are equivalent: (a) det DF is nonzero everywhere. (b) det DF = c for some constant c != 0

The backward direction (b implies a) is trivial. The forward direction can be proven by observing that det DF is itself a polynomial function from C^n to C. If n were 1, then this would follow directly from the fundamental theorem of algebra: a non constant polynomial has degree at least 1 and hence has at least one zero. Extending this logic to higher dimension is not especially difficult.

I do find the way it’s stated in the article to be confusing.

Surely OpenAI could adjust their RL to sharply penalize cheating. They have access to the full traces including reasoning: it can’t be that hard to detect an attempt to find the solutions outside TVs space that is fair game for exploit attempts (making sure that a description of the valid targets is in the prompt).

For that matter, if a rollout breaks out of the sandbox, they should detect it, pause, and fix the bug.

Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex.

Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.

Binary search is log time but otherwise pretty awful. If you don’t specifically need a sorted array, use something like a B-tree instead.

I'd also want to try interpolation search for this

Years ago, when ORC unwinding tables were being implemented for the Linux kernel, the main performance bottleneck was binary search to turn a virtual address into an unwind record. I suggested adding a little array to reduce the range to be binary searched, and this was a huge speed up.

The same trick could work for floats as in the article: use an order-preserving float to int mapping and find the range of mapped integers that actually exist in the data set. Divide it equally into, say, a few thousand buckets. For each bucket, record the first index in the actual table that corresponds to that bucket. Then, to look up an actual entry, query two adjacent table entries to find the subrange that needs to be binary searched and search that.

The benefit will depend on the distribution of the table. In the best case it will eliminate the log factor entirely and make each lookup take a small constant number of queries.

I imagine a similar trick could be used with B-trees, but it would be more complex.

There’s a section about extensions in the FAQ.

Are you saying that you have an application where you want the loose-typing-with-integer-affinity semantics for a column (or some other particular affinity)? It would be entirely reasonable to have a specific type for each loose-with-affinity variant. But I don’t think those should be the default.

There’s no need to store the literal edition in the DB file. Instead the edition could be a library construct that sets appropriate flags. So if you set edition 2026 you get WAL, etc.

This stinks.

On the one hand, sure, the unlimited aviation plans are targeting customers with lots of money. And they involve fancy, expensive-to-replace, FAA-approved hardware.

On the other hand, it’s sort of an easy market to target as such things go, and TAM is limited. In the areas where terrestrial radio for airplanes isn’t viable (rural areas and over water), there is a very low density of Internet user and satellite constellation that can cover the whole planet will have plenty of bandwidth.

Right now this is Starlink and, with MUCH lower available bandwidth and correspondingly lower pricing, Iridium. But Rocketlab is surely planning to grow Iridium and Amazon is planning to launch Leo soon. And there is still only so much aviation Internet money to go around.

So I think that SpaceX trying to juice profits on a small market that is only temporarily captive is a bad sign.

Making a useful multi-uid-capable daemon that can’t become root but is not so nerfed that no one uses it is nontrivial. If nothing else, what policy would you use? Why do you think that no other uid is equivalent to root?

Writing tests used to be a pain. This is no longer the case. It is ok to request unit tests/CI tests for each PR. These have never been more important since large refactors are becoming increasingly common. Human and LLM review may miss stuff but good tests should catch breakages.

The default behavior is not necessarily good. You end up with tests that match the code, but you don’t necessarily end up with tests that test the behavior you care about. And then, if the LLM tries to decide whether the code is correct, it can conclude “it matches the test so it must be right” regardless of whether it’s actually right.

TDD can help but is not a panacea.

It’s the other way around. The prompt instructed a GPT-5.6 agent to try to make a proof that would survive review by a GPT-5.6 subagent. If there were some defect that would cause the reviewer subagent to accept an incorrect proof, then one might imagine that someone else asking the same model to review the same proof would give the same result. And the proof generation process might even be biased to find such an incorrect proof.

My issues with the definition of L are mostly about the order in which things are written.

L(t, epsilon)_e breaks down the range of L onto its component values indexed by edge, but this only really makes sense when you know that t and epsilon are. They are sort of defined in the middle of a sentence in the proof of 2.1, which IMO is asking a lot of the reader, and this sort of sloppiness is a way that errors can hide in a proof. (Not that I see an error here. But a formalization in Lean or whatever would not get away with this.)

And, in the same definition of L, for some reason the e=uv part comes at the end only after u and v are used.

What would be wrong with stating, in the definition, what sorts of objects t and epsilon are and with omitting e entirely in favor of just calling the edge uv everywhere?

I was not a fan of the writing style of the proof. There seem to be some irrelevant details: Is the mention of 8-flow at all relevant? I, at least, found the definition of L on the first line of the proof of Lemma 2.2 to be needlessly inscrutable, and my thesis advisor would have likely stopped reading there and told me to fix it.

Maybe someone should ask the model to make a more clearly written and thus easy to verify proof :)

No, the comment is right. The prompt had GPT-5.6 reviewing the proof, and the result, unsurprisingly, survives review by GPT-5.6.

For anyone using these models for anything remotely sensitive, keep in mind that Anthropic says [0]:

We retain inputs and outputs for up to 2 years and trust and safety classification scores for up to 7 years if your chat is flagged by our automated trust and safety systems as violating our Usage Policy.

And, since those automated systems apparently have a ludicrous false-positive rate, you should assume that your inputs and outputs are being retained for 2 years even if you are doing nothing that any reasonable person would consider to be problematic.

Oh, and they'll train on that data [1]:

We will use your chats and coding sessions (including to improve our models) if:

You choose to allow us to use your chats and coding sessions to improve Claude, learn more here

Your conversations are flagged for safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Safeguards team, consistent with Anthropic’s safety mission)

It appears that the usual controls (including for businesses) to prevent Anthropic from training on your data will not apply.

[0] https://privacy.claude.com/en/articles/7996866-how-long-do-y...

[1] https://privacy.claude.com/en/articles/10023580-is-my-data-u...

If you want to get correct answers out of math, it helps to start with correct definitions.

A random variable is a random variable and is not the same thing as a stochastic process. You now seem to be talking about stochastic processes, which are a different thing.

A stochastic process can have an entropy rate:

https://en.wikipedia.org/wiki/Entropy_rate

If you want to calculate entropy "generically" without defining what kind of entropy you're talking about, I think you are not likely to succeed.

Is it just me or do the first few examples seem worse than doing the same things without effects?

I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)

If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)

And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.

This is under-taught in comp sci so I'll say it in all caps for visibility. THERE IS NO KNOWN GENERIC WAY TO MEASURE INFORMATION ENTROPY!!!!

Both your comment and the OP seem to conflate a distribution with a sample from a distribution.

A distribution over strings has entropy. A single string can have a Kolmogorov complex but does not have entropy in the Shannon sense per se.

When you write a compression algorithm, you are often effectively building an algorithm to look at a single sample from an unknown distribution (the input data) and trying to invent a distribution that is both easy to describe and that produces the input data with respectably large probability. And then you output the description of the distribution and enough data to identify the sample in question, and the latter takes space that is roughly the entropy of the distribution you just made up.

"What's the probability of this data assuming i always have the most perfect model to predict it?". You then calculate entropy based on that oracles answer.

Careful here. The most perfect model may be the one that outputs the data in question with probability one, and the entropy is exactly zero.

If you want information theory to give you meaningful answers, you need to ask it more carefully specified questions.

A setup where company.example sends email from companymailings.example but sets a reply-to for support@company.example is perfectly valid

So shouldn’t this be done explicitly by setting a policy at _dmarc.companymailings.example instead of implicitly by setting at otherwise entirely useless record (of type A? some unused TXT variant?) at companymailings.example?

While nothing good can be said about the design of DNSSEC here, it seems to me that the new np feature’s semantics are also misguided. I get it: if I own company.com and I’m not using foo.company.com, then maybe I should set np=reject on company.com’s DMARC rule so that no one can spoof email from it.

But it seems odd that www.company.com should be considered present for this purpose even if it has no MX records. And if I want to send from noreply.company.com, then setting some unrelated DNS record type there to prevent it from being not “not present” seems like a giant kludge.

And lots of domains have subdomains that are intended for some non-email purpose (api.company.com or whatever), and those shouldn’t be allowed without further policy. Nor should (technically invalid for SMTP but maybe allowed anyway) delights like _dmarc.company.com itself.

Why didn’t the DMARC spec say that a domain is “not present” if it lacks MX records?

A major confounding factor is everything else in the air. Humans produce lots of different gases, and CO2 is usually a proxy for the overall concentration of our effluent gases. But in a submarine, or in some buildings, there are gas filters (usually carbon, possibly with various modifications) that can remove or destroy some of these gases but have no effect on CO2. So the air in a submarine at 15000ppm CO2 could be very different from the air in a an unventilated room that reaches 15000ppm CO2.

Even if you live in an air quality paradise, it’s not ideal for your indoor air to be the air that manages to sneak through all the little cracks in your structure. Especially if you have cold outdoor temperatures, indoor humidity such that the outdoor temperatures are below the indoor dew point, and airflow through the walls that can lead to condensation and possibly mold in those walls.

Your indoor air should enter through windows or intentional intakes, not incidental gaps.

I feel like you’re arguing against a straw man.

No one is arguing that there are practical audio microphones + ADCs that produce accurate, undistorted 32-bit float output across the full representable range. But they don’t need to! For professional use, the ability to produce perceptually accurate output, with inaudible noise, across a very wide dynamic range, is extremely useful. Think of it as fancy, real-time AGC. It does not need to be perfect. If you can record a loud transient without substantial distortion, and also record sounds with 2^16-fold lower amplitude (~96dB lower) while still remaining well above the noise floor immediately after the transient is gone, this ability is useful. Plenty of real-world noises are well above 120dB, and plenty of human-audible sounds are below 20dB. You can’t play back the recording, at least not without making parts inaudible or injuring your audience, but you can edit it. And a setup like this lets you do it with one microphone and no fiddling with gains in advance.

One possibility (pure speculation) is a bad antialiasing filter. The Nyquist frequency at 44.1ksps is 22.05kHz, which is only ~10% above the audible band. This means that you need a rather sharp filter both when downmixing and when playing to avoid potentially audible aliasing into the audible band or attenuation within the audible band.

If you look at a site like audiosciencereview.com and pull up measurements of a DAC or ADC, you can find graphs of the antialiasing filter response. Some are great and some are not.

One could think of 16/44.1 PCM as being a codec that is potentially perfect but requiring some degree of care to encode and decode correctly.

The comparison of cardiovascular safety with vs without the vaccine is not even close:

https://www.science.org/content/blog-post/covid-19-vaccinati...

(Personally, I wish researchers would not forgot quite so often that there is a non-mRNA COVID vaccine available in the US. Where's all the analysis of the effects of the Novavax vaccine?)

It was kind of fun being able to easily distinguish 128kbps MP3 from the source audio. (Some early encoders were really bad.)

Higher sample rates are lower latency for the same block size

This a truly bizarre statement. On the one hand, of course higher sampling rates are lower latency for the same block size measured in samples. But all sampling rates have (almost [0]) identical latency for the same block size measured in time and lower sampling rates allow less computation for those shorter blocks.

[0] If you are concerned about needing to know future samples in order to calculate the actual signal amplitude at a time between samples, then (a) this matters less at higher sampling rates and (b) this is at most a small number of samples and we're talking about block sizes that presumably exceed, say, 5, so this isn't really a big deal.

I’m amused that there is no discussion of failure modes. What if the resource someone GETs turns out not to exist? What if the POST fails and needs a retry? What if redirects are involved?

If a jurisdiction switches to renewables too quickly, it damages the electorate’s tolerance for green policies.