I'm not sure of a good structure for a new flush class, but i recall it is
very obvious if the parts are thought about together.
I end up writing a new class structure, because so many of the parts move
around when changing how the data is organized.
Thinking about retaing memories around a behavior with some complexity to
it, while repeating it excessively with changes to it.
ok here's what to do, i think:
-> find the largest subtrees on both sides of a write
-> start from each subtree and walk toward the write, accumulating the
largest full subtrees possible
this collects data that isn't changed together into a single reusable
full tree to be quickly referenced in
O_ !
k what's up?
i have a computer with a partial implementation on it
i'm not sure why to select "full" subtrees but i understand it
optimizes the case for appending or prepending data, producing
balanced trees with few new index nodes.
I had a really great brief ability to think of trees normally, and it seems
the thing to do is to ensure that every included entry in an index is a
full tree (# leaves = 1 << height) (since new leaves are flushed in the
same data as the root, "balanced" trees have unbalanced shape with extra
Thinking on balanced trees.
What kind of update properties are needed to retain the balanced tree
behavior, where few index updates are needed for append-to-end behavior?
For one thing, there's a deep subtree that is copied up as the same
reference repeatedly. If my code is functioning
Thinking of lookup data.
Say the root were included in every tip update. The root could reference
the locations where its immediate child internodes are. The important ones
would be the final updates that fill a subtree, as these have access to the
location of every leaf.
Before a subtree is
A core point here is that the n/2 nodes and leaves are never touched. The
subtree stays exactly the same until the max height increases by 1. This
could be good to verify.
Then, what data goes in updates after the first new leaf for a new root?
I remember there's an old mainstream project that does this, but I don't
remember what it is off hand very well. Anyway it basically just used
whatever the clearest approach was.
First update is first root.
Second update makes two leaves. The new root goes in the second update,
with both leaves
