i3oi3's comments

Interesting approach. I just finished some work for a similar task in a different domain.

One thing that surprised me: tantivy's BM25 search is faster, more expressive, and more scalable than SQLite. If you're just building a local search (or want to optimize for local FTS), I would strongly recommend looking into tantivy.

If you have the resources, it would be very interesting to throw a some models (especially smart-but-context-constrained cheaper ones) at some of the benchmark programming problems and see if this approach can show an effective improvement.

You bet I do. That's an hour of rubber-ducky time working through new architectures with someone who won't get tired of my endless blathering. I've worked through a bunch of bad ideas that way, without embarrassing myself in front of my colleagues.

I also use it to explore topics that I wouldn't spend desktop time on, but that I was curious about. It's like having a buddy who's smarter than me on their special interest, but their special interest is "everything you don't know.". And your buddy's name is Gell-Mann. : - )

It beats passively listening to the radio.

You know what's pretty good at cleaning up data that's a total trash fire? _More_ LLM. :-)

I run a web service whose primary purpose is cleaning up messy, SEO-enshittified data from Google, eBay, etc. After years of fine-tuning my own heuristics, I threw a super-cheap LLM at it and it massively out-performed my custom code. It's slower, but the results are well worth it.

The description of the algorithm notes that each irregular pentagon is divided into four sub-pentagons. Eyeballing the maps, I don't see any group of 4 pentagons forming a similar larger pentagon.

I noticed that you had an analog to the H3 landing page on your landing page, allowing zooming in. If you could also steal the next-higher / next-smaller overlay like they did on the H3 landing page, it would make it clearer the relationship between the larger and smaller pentagons.

I've used H3 extensively, and one of the things that always bugged me about it was that each large hexagon was _mostly_ covered by a group of the next smaller ones, but because geometry, the edges have some overlap with the neighbor large hexagons. So I can't just truncate an integer mapping, for example, to get the ID of the next-largest.

Are the examples all actual outputs of the program? It's entirely possible that my understanding of the grammar is off, but it looks like these examples are wrong:

$ echo 'cat dog' | trre 'c:bat|d:hog' bat hog

$ echo '' | trre ':a*' # <- do NOT do this dog

$ echo '' | trre ':(repeat-10-times){10}' dog

We got one, and we love it. My daughter dropped hers and bent the case. We ordered a new case (which, admittedly, was a significant percentage of the price of a new laptop) and had it repaired within an hour of delivery.

That was my first thought also. OTOH, Framework's business model is "we're going to charge you more to get that thing you actually wanted without locking you into stupid business models."

I would absolutely pay a premium for a decent TV without all the advertising crap that pops up every time I turn on the TV.

Dragons Egg by Robert Forward had always been one of my favorites. Asks the question "what would like be like if it evolved on a neutron star," and has 20 pages of his notes on working out the physics at the end of the book.

They did make a straight album, cleverly titled "The Smothers Brothers Play It Straight."

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

Hansen's Second Law: Clever is the opposite of maintainable

There is nothing that will stop a code review quicker than "I discovered a clever way to..." A dozen engineers are going to have to try to reverse engineer your cleverness in order to safely make any change to your code, so you'd better make double-sure that the performance you're buying with your cleverness is worth the total maintenance cost going forward.

There are some times it's worth it (the Fast InvSqrt hack and many others), but most of the time, it's just tickling our intellectual curiosity for our own benefit, and that's a bad trade.

I was discussing low-load index investing with a friend, and the 7% over the last 200 years sounds great.

He suggested the hypothesis that that's a reflection of the rise of the United States as a superpower over the last 200 years, and if anything were to impugn the United States' status as the market of refuge, those numbers would not be predictive of consistent long-run returns in the future.

That's a hard hypothesis to refute. Are there similar long-run numbers from all stable countries around the world, or is the US market unique in that aspect?

Some areas that I explored more deeply in my Earlier Days w.r.t hash tables (Java hash tables, at that) that aren't covered by the analysis are:

* Memory footprint and GC load

* Write performance (especially characterizing fast-path vs. rebalance times)

* Loading vs. performance tradeoffs (can the table perform well with 80% occupancy? 99%?)

* Small-table utilization.

If some of the implementations consume substantially less memory and/or GC churn while having largely indistinguishable lookup performance, then they're a win for value. This is one place that open addressing can win.

For the libraries we were writing, we didn't know if consumers would be stuffing in one element (the most common case) or millions of elements (uncommon but important), so we ended up implementing a clever abstraction that would start with a pointer to the single object, then replace it with a hash table when the second element was added. Since we used hash tables like country doctors prescribe aspirin, it reduced the heap footprint of the server by ~30%. Of course, Hansen's Law states "Clever is the opposite of maintainable," and that definitely applied here.