[ot][spam][personal] notes/spam/memorization: append-only random writes

Undiscussed Groomed for Male Slavery, One Victim of Many gmkarl+brainwashingandfuckingupthehackerslaves at gmail.com
Mon Aug 22 11:03:31 PDT 2022


forwarded to help me find it

Forwarded Conversation
Subject: [ot][spam][personal] notes/spam/memorization: append-only random writes
------------------------

From: <cypherpunks-owner at lists.cpunks.org>
Date: Mon, Aug 22, 2022 at 1:52 PM
To: <gmkarl at gmail.com>


Only subscribers may post to this list. Visit https://lists.cpunks.org
for subscription information.




---------- Forwarded message ----------
From: "Undiscussed Groomed for Male Slavery, One Victim of Many"
<gmkarl at gmail.com>
To: cypherpunks <cypherpunks at lists.cpunks.org>
Cc:
Bcc:
Date: Mon, 22 Aug 2022 13:51:48 -0400
Subject: [ot][spam][personal] notes/spam/memorization: append-only random writes
With the append-only random writes, a basic concept is data
representation of index nodes, and how this differs from data
representation of data.

It makes sense to me to implement them as objects, although I haven't
learned design since OOP in the 90s, technically: it wasn't really
different from modules in C, just used cleaner syntax. So maybe my
knowledge is relevent.

So, an object for data, and an object for indices (inner nodes), or whatnot.

A core function is taking slices of inner nodes, and then
recalculating their leaves and lengths and integrating them into a
balancing strategy.

So, the reason to make an object for indices, is to facilitate taking
their slices and acquiring their new leaf count.  A balancing strategy
will want to know their depth and their leaf count.

- taking slices of inner nodes (index objects), and getting the leaf
count and height of these slices
- index objects then reference such slices alongside data nodes, in a tree

not too complex. The tree is the index class ... almost .

The big challenge for me is bringing the parts together. Making them
simple and clear seems helpful.

- Taking slices of a tree, and calculating the leafcount and height of
the slices.


----------
From: <cypherpunks-owner at lists.cpunks.org>
Date: Mon, Aug 22, 2022 at 1:56 PM
To: <gmkarl at gmail.com>


Only subscribers may post to this list. Visit https://lists.cpunks.org
for subscription information.




---------- Forwarded message ----------
From: "Undiscussed Groomed for Male Slavery, One Victim of Many"
<gmkarl at gmail.com>
To: cypherpunks <cypherpunks at lists.cpunks.org>
Cc:
Bcc:
Date: Mon, 22 Aug 2022 13:56:30 -0400
Subject: Re: [ot][spam][personal] notes/spam/memorization: append-only
random writes
Taking slices of an index tree (i.e. index node) can seem confusing.

The quick 'flat_tree' code I wrote for my semi-successful 'log'
project doesn't retain copies of old trees after they are published.
It stores just one tree, containing references to old copies of
itself.

For interconnecting disparate data, it seems it would make sense to
let the system introspect into the tree, and look at it. This could
mean providing for retaining the old copies, or it could mean
accessing the network. [some confusion around the data already being
available, unsure of these .... in the general case it would not be
...]

So, the nodes might have some abstract way of taking the slices. A
quick implementation would not calculate or optimize anything, just
summing the leaves of the children that overlap the slice.



----------
From: <cypherpunks-owner at lists.cpunks.org>
Date: Mon, Aug 22, 2022 at 1:58 PM
To: <gmkarl at gmail.com>


Only subscribers may post to this list. Visit https://lists.cpunks.org
for subscription information.




---------- Forwarded message ----------
From: "Undiscussed Groomed for Male Slavery, One Victim of Many"
<gmkarl at gmail.com>
To: cypherpunks <cypherpunks at lists.cpunks.org>
Cc:
Bcc:
Date: Mon, 22 Aug 2022 13:58:13 -0400
Subject: Re: [ot][spam][personal] notes/spam/memorization: append-only
random writes
An index node class could then have an abstract/overrideable function
for taking a slice. A default implementation could naively simply sum
the properties of the intersecting children.

Alongside that, we have a data/leaf node representation.

And an index node class, with an abstract method/member function for
taking a slice.


More information about the cypherpunks mailing list