Already superceded by 3.54.1, mostly due to a memory corruption issue on 32-bit builds.

I'm still holding on releasing my Go bindings on another just uncovered performance bug.

It's honestly been the most unstable .0 release I remember. If this is what a frenzy to fix LLM reported bugs causes to a well established project, I don't know what the future holds.

This is very cool.

SQLite uses the "streaming" push/pop/eval API for windowed aggregates.

DuckDB implements "segment tree aggregation" by swapping "combine" for "pop".

This means I can offer an adapter that turns combinable aggregates into invertible aggregates, in amortized O(1).

> "median of medians" (finding the median in a list in O(n) worst-case time) is useless because it is not used in practice.

This one is just not true. Here it is in 255 lines of well commented Go code: https://github.com/ncruces/sort/blob/v1.0.3/quick/quick.go

It's worse case linear, as used for sorting it beats the Go standard library on the average and worst cases, lagging a bit on the best cases.

In my experience, median-on-ninthers (which is only slightly more complicated than median-of-medians) definitely beats both heap sort and particularly heap select as a fall back for the degenerate case.

And it's not just academic: I've sped up significant stuff at work by switching from sorting to partial sorting and/or selection.

That's not median-of-medians, that's quickselect. Quickselect is useful and practical yes. Theoreticians don't like it because of the randomization (or non-worst-caseness)

> In computer science, the median of medians is an approximate median selection algorithm, frequently used to supply a good pivot for an exact selection algorithm, most commonly quickselect…

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

That's pretty much what I posted: median-of-ninthers is an evolution of median-of-medians, that I use to pick a better pivot whenever the pivot supplied by median-of-3 turns out to be bad.

Using it all the time would simply make quicksort/quickselect about twice as slow as it is now, but still faster than heapsort/heapselect. It's a better backstop algorithm than the common introsort/introselect.

There's also no randomisation, the implementation is completely deterministic, and depends exclusively on the input order.

And median-of-ninthers is faster, but median-of-medians is far from terrible, so calling it a galactic algorithm or completely useless in practice is far from the truth, IMO.

Shameless plug: if you value Go, and CGO_ENABLED=0, and SQLite, and are worried about C in a web server and RCEs, may I interest you in my SQLite driver?

https://github.com/ncruces/go-sqlite3

I just wrote up the security goals of the tool I use to translate C to Go: https://github.com/ncruces/wasm2go/blob/main/SECURITY.md

I obviously can't make any promises, as it's just a personal pet project, but those are the goals, and they do catch memory corruption bugs in practice: https://sqlite.org/bugs/forumpost/543f94984b

Thanks for writing this library! It's great. I've used it a couple of times and never had an issue

FWIW, there's modernc.org/sqlite which already provides pure Go sqlite implementation.

Might be useful to test your own implementation against.

I do. I had it listed in my own README as an alternative for a long, long time, and both show up in these often posted benchmarks: https://github.com/cvilsmeier/go-sqlite-bench

But for the point I was making, it is in fact not an alternative. In my version each SQLite connection is confined to a sandbox, and a C memory bug cannot corrupt the Go runtime, call stack or heap. In their version, a C pointer becomes an unsafe.Pointer that can address all Go memory.

For OpenAI/Anthropic/etc it's apparently not enough to be the tool that helped a mathematician with a discovery/proof/etc.

They need to state it was entirely autonomous.

I don’t blame OpenAI for that. There’s a ton of weirdly politically motivated denial of AI being useful for solving problems that require new answers. This is one of the very few possible ways to objectively prove that AI can do that.

What's more, it's quite possibly one of the best ways to improve AI, as math provides both a large corpus of training data and an objective way to measure capability. IMO this is likely why the AI companies are working on this, with improvement in math reasoning bleeding over into improvement in general reasoning.

Really, mathematicians should be thrilled about this, as this could be the biggest practical payoff of thousands of years of investment in math, bigger even than all the preceding science and engineering payoffs. We're told one of the benefits of a math education is learning how to think; was it really so unpredictable if that also applied to machines? This sort of payoff would justify wide open checkbooks for more math research, even by humans.

Well yeah, their ultimate goal is to develop "highly autonomous systems that outperform humans at most economically valuable work"

More comments than upvotes make it sink, because it's a contentious topic.

That's the app they used:

The phyphox app recorded acceleration and angular velocity at a sampling rate of 100 Hz.

I wonder if they considered using the fact that a roller coaster trajectory is closed loop? That tends to help with calibration, but maybe the devices are nicely factory calibrated to begin with. They get close, but stop short of mentioning it:

The measurements were stopped after the attraction returned to its resting state. This provides reference points at the beginning and the end of the ride where the velocity is zero.

And this gets you real close to building visual inertial oximetry:

Smartphone video recordings were used to correlate specific ride manoeuvres with the recorded data for the roller coaster.

>I wonder if they considered using the fact that a roller coaster trajectory is closed loop

In terms of the rider, this isn't always the case. Often, the unload station is separate from the load station, basically pipelining. Also for theming; for example, Disney's Space Mountain has the unload and load zones on separate floors.

The paper did use the fact that velocity was 0 when they started and ended.

For OSS work, I actually rather like finding out what other people I follow are up to.

A list of tasks I'm already behind on is the last thing I want to be reminded of constantly.

:)

The feed is still there, but imo it’s not the default thing many people wanna see when visiting the dashboard. I understand that people want the feed, but this weird social network thing isn’t really the true purpose of Github in 2026, and I would bet Github has the data on that and decided that what people really want to see when they first open .com is the status of their own work.

I'm not complaining, just offering a different PoV. :)

Because (maybe particularly) at 1e100 scale, having a super intelligent butler that does whatever everyone asks of it can easily get you to hundreds of thousands of daily PRs merged to the monorepo, but won't necessarily help coordinate efforts, and may actually cause certain projects to collapse under their own weight.

Because none of the people who can use it (have been and will be using it) can talk about it if it hasn't been announced. NDAs and stuff.