ncruces
SQLite has gone into a frenzy of bug fixing this past year, changing long stable processes to ease things up: opening a specific report channel just for these kinds of bugs, adding features to Fossil to help manage things on their end (and that's just the visible stuff).
And with all that, the latest release has unfortunately been the buggiest I've experienced so far.
I skipped the .0 because of a crash, and only released .1 after giving up waiting for a .2 that never came, with a patch to fix a serious performance regression.
I spent a month supposedly shipping old bugs no one had a problem with, rather than shipping new bugs that instantly crashed things or caused measurable regressions.
That's on a software with stellar testing, and a good engineering team known to favour stability over the new shiny.
It doesn't have the mechanical beauty of an automatic with a perpetual calendar, but is otherwise better in every way that matters, and it is just as pretty.
This is especially true around earnings, not necessarily for some sinister reason, other than it's material information that can influence the market.
What I like about immutable treaps is that, if you using hashing rather than randomness, you can achieve O(1) equality for entire trees.
Unfortunately, my current language of choice makes hash consing too slow.
In fact, a problem with LLMs is that they consistently write more than I want to read.
Now it's only worth it to hack a website that's asking to be hacked if the prize is $15k.
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.
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).
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.
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.
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.
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
They need to state it was entirely autonomous.
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.
A list of tasks I'm already behind on is the last thing I want to be reminded of constantly.
:)
Both offer direct, mechanical engagement that avoids the continuous friction slip of a wet clutch.
Which was the point.
Also platforms like Wasm still do Mx1 scheduling without async preemption, where Gosched is required at places.
E.g.: my "transpiled" SQLite driver takes special care to make sure long running SQL queries (and the busy handler) can be canceled with contexts even on platforms without async preemption.
It doesn't need to say if you do any business with Anthropic (for other customers, internal tools or processes), you lose all your contracts with us.