Hi Ben, On Tue, Aug 17, 2021 at 6:24 PM Ben Goertzel <[email protected]> wrote:
> > > need from "Atomese 2" language (which will probably get a wizzier and > more appropriate name soon). You're good at naming things. Naming things is hard. > On roughly the same timescale, Senna will likely have a document > summarizing his current thoughts on distribution/persistence for > Hyperon, on which it also will be excellent to get your feedback .... > I can make some pre-emptive remarks now, based on what I saw in earlier drafts. (1) UUID's are a really bad idea. The problem is that issuing a UUID requires a central authority that will guarantee that the association between the UUID and the Atom is really unique, is the right one. It becomes hard to communicate with the central authority; it's a bottleneck. Solution: Just use the Atom name. For example `(Evaluation (Predicate "foo") (List (Concept "bar")))` This is globally unique- its the same on Jupiter as anywhere else. It's easy to compute - there's nothing to do. If you need to send this to a peer node, just send it as a string. If you want, then compress that string with some compression algorithm. Or invent a binary format. (I don't care) There is a speed-cpu-time tradeoff. If you really want -- use an ID -- but that ID is for that one communications link only -- its not "universally unique". The problem with ID's is that you need to keep a lookup table, of ID vs. the actual Atom -- and this lookup table chews up RAM. Its a significant amount of RAM. And doing the lookup is slow -- it can be 30% of performance. That's because Atoms are so tiny, so fast, that doing almost anything at all will just make everything slower. So even very simple ideas, very simple concepts, make things slower. Performance is a straight-jacket, there's just not a lot of wiggle room of what you can do without making things slower, fatter. (2) DIstributed, federated, decentralized .... Decouple the policy of what atoms are sent where, from the mechanism of how they are sent. If the TV on some Atom is being updated 1000 times a second, it makes no sense to try to broadcast it to the world at the same rate. (3) Allow multiple policies to be used. Allow multiple channels to be used. And finally: (4) Senna and you may not like it, but points 1-3 are more-or-less done, already. The demos work. Run the demos. I mean -- they already do everything that was written down in the 2017 design documents. So, in a sense, there's "nothing more to do" to get a decentralized AtomSpace. The next steps are these: (a) If you don't like the communications channels that are there, you can create new ones. I don't care. I think that what's there is "good enough for most purposes", but if you want to tune for something super-fancy .. sure. Do that. It can fit just fine in the existing API. I really doubt you'd need to change the API to get what you might want. (b) Create some policies. A policy is just some Agent that passes some Atoms along from here to there. In what I do, I have not needed anything except for the most trivial policies, but certainly I can imagine getting fancy. This really would be new, cutting-edge work. But its entirely detached from the question of "how do I send an Atom from A to B" (that's the commo layer) and "how do I keep an atom in RAM" (that's the core AtomSpace) Working on (b) is really what decentralized atomspaces are really about. That's where all the action is. That's the unexplored, unknown, interesting bit. You can invent new commo layers - its real easy; everything you need is there. At this time, it would be hard to invent "a new way to store an Atom in RAM" ... and have it be API compatible. This can be done, I suppose, but it would be a challenge. I'm up for it, but it's hard to see that this is needed or useful. I mean - I'm open to anything, but its real easy to make a system that is slower and bulkier, and hard to make one that is faster and slimmer. I say this out loud because I suspect Senna (and you?) might be thinking of "new ways to store Atoms in RAM", and that's fine, but it is really not at all about distributed Atomspaces. I'm also concerned that there is a tangle between sending Atoms from A to B (the communications channel) and deciding which atoms to send (the policy). These two need to be kept separate. Tangling them together would be a fatal error. -- Ben > > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CACYTDBdT_9t4AbUOG0_WvMM%2Bmo8moxFCFzcyFUxwAGfmm_t%2BbQ%40mail.gmail.com > . > -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35Ok9WhBmq%2BSL_LL7mhBsjJgoG33%2BL3ftwtsJN88euEwQ%40mail.gmail.com.
