ncruces
Joined 3 years ago
Joined 3 years ago
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