forwarded to help me find it Forwarded Conversation Subject: [ot][spam][personal] notes/spam/memorization: append-only random writes ------------------------ From: <cypherpunks-owner@lists.cpunks.org> Date: Mon, Aug 22, 2022 at 1:52 PM To: <gmkarl@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@gmail.com> To: cypherpunks <cypherpunks@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@lists.cpunks.org> Date: Mon, Aug 22, 2022 at 1:56 PM To: <gmkarl@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@gmail.com> To: cypherpunks <cypherpunks@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@lists.cpunks.org> Date: Mon, Aug 22, 2022 at 1:58 PM To: <gmkarl@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@gmail.com> To: cypherpunks <cypherpunks@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.