Re:Show HN: Lisp with GC in 436 Bytes
by remexre on Monday December 20, 2021 @09:57PM
(#29633282)
Though I think Clojure has a linear datastructure that's O(log32(n)) for all the common ops. (This is the one with all the memeing because someone called it "practically O(1)".)
[ Parent
| on HN ]
Re:Show HN: Lisp with GC in 436 Bytes
by dan-robertson on Tuesday December 21, 2021 @06:18AM
(#29636273)
Right, and updates are also O(32 log32(n)) rather than O(2log2(n)), rather than O(1) for arrays. It’s a bit more complicated when you think about cache lines being updated but mutable arrays massively win on cache
Why do you have a constant before the log term? Isn’t that completely meaningless?
Re:Show HN: Lisp with GC in 436 Bytes
by dan-robertson on Tuesday December 21, 2021 @07:56PM
(#29644189)
It is meaningless mathematically. It’s as meaningless as the parent talking about log32(n) because of course log32(n) = log n / log 32, so there is just a constant of 1 / log 32 being put at the front.
I think the subtext is really a statement about constant factors. The parent is saying “if trees are wide then lookups are cheap” and I am saying “if trees are wide then updates may be expensive” (to update an immutable binary tree of size n, you must allocate log2(n) nodes of size (say) 3. To update a 32-ary tree you need log2(n) / log2(32) = log2(n) / 5 nodes of size 33 so, as 33/5 = 6.6 > 3, the wider tree requires more allocation for updates.)