Ben,
On Mon, Nov 8, 2021 at 6:29 PM Ben Goertzel <[email protected]> wrote: > Doug, can you point me to documentation on the ALEPH-like inductive > reasoner you mention? > > Oops! I haven't written documentation. (That is one of my worse traits) But can at least point to my code: https://gitlab.logicmoo.org/gitlab/logicmoo/logicmoo_workspace/-/tree/master/packs_sys/logicmoo_ec/prolog/ec_planner I used the word "inductive" in my email because the process of program creation is normally part of the culture of "Inductive Logic Programming (ILP)" but the actually method I am using is closer to "Abductive Event Calculus" (written about by Erik Mueller/Murry Shanahan) How this works is it takes a "starved list of events" (SLoE) that happen in the world and a "library of primitive [program] scripts" (LPS) that can make stuff turn out a certain way. It then takes the SLoE and fills into the middle of it the LPS like: SLoE-1 --> LPS-a --> LPS-b --> SLoE-2 Then the system memorizes this as a part of the "induced" program. I should actually document how it works.. even for my own sanity Here is a paper on ALEPH (in case anyone isn't familiar) https://www.cs.ox.ac.uk/activities/programinduction/Aleph/aleph.html > thx > ben > > On Mon, Nov 8, 2021 at 6:16 PM Douglas Miles <[email protected]> wrote: > > > > > > > > On Mon, Nov 8, 2021 at 10:02 AM Linas Vepstas <[email protected]> > wrote: > >> > >> Hi Douglas, > >> > >> Interesting email... > >> > >> On Mon, Nov 8, 2021 at 12:14 AM Douglas Miles <[email protected]> > wrote: > >> > > >> > > >> > guile-log would be an ideal system as it supports overloaded > unification (overloaded from scheme) > >> > > >> > It would be nice to allow Prolog programs to be ran and maintained as > Atomeese and vice versa > >> > >> I can suggest several solutions, and can even offer to write some of > the code. > >> > >> As of very recently, you can now store arbitrary s-expressions in the > >> atomspace. These are stored in such a way that they are searchable. So > >> you can write "(junk stunk)" and "(stuff stunk)" and then ask "find > >> all s-expressions with 'stunk' at the end of them". (or any other > >> query). > >> > >> So, if you can convert prolog to s-expressions, they can be stored. > >> > >> Another possibility is that I can store prolog "natively". Or any > >> language, for that matter: python, perl, java, javascript ... just > >> provide me with a parser (written in C/C++) that will convert that > >> language into an abstract syntax tree, and I can store that tree. The > >> query engine can then query such trees. > >> > >> I was going to do one for JSON but got immediately bored. Storing it > >> in the atomspace is easy, but so what? The only "interesting" part > >> would be to write a query language, but that exists already: > >> "GraphQL", and so I could port graphQL to sit on top of the pattern > >> engine, but so what? Who cares? > >> No one would use such a thing. It seemed pointless. > > > > > > I often realize too late the amount of utility such things provides on > paper sounded good.. but as soon as I have it I ask "now what?" ( Just > because people can query my system in their format of choice does not mean > that they will want to ) > > > >> > >> So again, provide me with trees, and I can store/search trees. It's > >> not hard. > > > > > > In prolog, when i want to be searching trees I organize my trees into > graph nodes (a predicate per arc) and search that way. That tree > structure usually stored in a prolog hashmap or other structure.. but I > have do do a small conversion to predicate arcs first to make search > efficient. > > > > > >> > >> The "hard part" is inventing a query language that users > >> would want to use. The raw, low-level pattern matcher language is > >> powerful but verbose and intimidating to new users. Some > >> domain-specific language would be more socially appealing. > > > > > > In my case the reason I produce the "efficient [at least to prolog] > structure" is for my program to be able to search and use the tree. It > would be hard to make it socially appealing as you say something else is > going to be better. > > > > > >> > >> > >> Hmm. But that is not what you wrote. You wrote > >> > >> > It would be nice to allow Prolog programs to be ran and maintained as > Atomeese and vice versa > >> > >> and that is kind-of harder. One possibility is that prolog programs > >> could be converted into URE rules, but the URE was designed for > >> probabilistic inference, and so would run slowly for crisp-logic > >> prolog. > > > > > > I'll try to restate the problem I think you are pointing out: Normally > lightning fast prolog programs are fast because they are leveraging > crisp-logic but will run slower because they would now have to compute > probability at each step? > > > > > > Now separately my usecase: > > > > > > I have 3 prolog programs that I was considering trying to convert to > URE/Atomeese: > > > > > > One is the ALEPH-like (an inductive reasoner) that computes/guesses new > rules that recreates the data observed (high-level sensory data or > whatever) called LPS-ALEPH > > > > And the other is one that creates an imaginary playable world .. (to get > a understanding, here are some rules it uses > > > https://github.com/logicmoo/prologmud/blob/master/prolog/prologmud/vworld/world_2d.pfc.pl#L210-L241 > ) PrologMUD > > > > With the combination of the two programs I am working on a system that > allows the ALEPH-like program to observe the Prolog Virtual World (Hand > coded in rules) and have it create a 3rd program in Prolog/Atomeese > Virtual World called NomicMU. So LPS-ALEPH's goal is to create an > inductive copy PrologMUD program into NomicMU and continue to make > additions and edits. > > > > What I am imagining is making my system more socially acceptable to > OpenCogers by having these (three) programs exist and run as Atomeese > instead of prolog. > > > > > >> > >> I have a partial fix for that: I think I can make a "simple" > >> fast forward-chainer on the pattern engine; this would fit prolog much > >> better. > > > > > > > > > > > > > > > >> > >> > >> This demo: > https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/recursive.scm > >> shows how to do recursive queries, and so prolog would be a > >> fleshed-out version of that demo. > >> > >> To convert (a subset) of atomese into prolog is "easy": just write > >> some code that takes atomese trees, and prints them as prolog. Of > >> course, you can't convert everything; prolog isn't powerful enough. > >> > >> -- Linas > >> > >> > > >> > - Douglas > >> > > >> > > >> > On Sunday, August 29, 2021 at 2:51:19 PM UTC-7 linas wrote: > >> >> > >> >> Hi Anatoly, > >> >> > >> >> I think it would be interesting (useful?) to write dynamic, run-time > shims between the AtomSpace and prolog (or other systems). The user would > write a small shim or conversion template, for example, something like > >> >> > >> >> :- x(y,z); <<==>> (Evaluation (Predicate X) (List (Concept > Y)(Concept Z))) > >> >> > >> >> or whatever mapping the user wants, and then every time prolog needs > this info, it could fish it out of the atomspace, and vice-versa: whenever > prolog generates output, it would automatically be written into the > atomspace. > >> >> > >> >> I haven't really thought about this for prolog, but I did think > about this for external data stores. Currently, the only way to get data > into the atomspace is a giant batch import, and this can take an hour or > two to run (e.g. the agi-bio dataset). It would be nicer to do this "on > demand", "as needed". Output is likewise: instead of one big dump, just > update the remote dataset bit by bit. > >> >> > >> >> I thought about this a little bit, and I think it's doable and not > that hard. I don't have any incentive to work on this, just right now. > >> >> > >> >> On Tue, Aug 24, 2021 at 2:53 AM Anatoly Belikov <[email protected]> > wrote: > >> >>> > >> >>> > >> >>> > >> >>> you can write something like that: > >> >>> ?- assert(likes('Bob', exploration('space', ('rockets'; > 'solarsails')))). > >> >>> true. > >> >>> > >> >>> It almost works, but I can't make prolog to return all the > solutions: > >> >>> ?- likes('Bob', exploration('space', X)). > >> >>> X = (rockets;solarsails). > >> >>> > >> >>> ср, 18 авг. 2021 г. в 21:02, Linas Vepstas <[email protected]>: > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Wed, Aug 18, 2021 at 5:32 AM Anatoly Belikov <[email protected]> > wrote: > >> >>>>> > >> >>>>> What do you mean by Prolog not allowing trees? > >> >>>> > >> >>>> > >> >>>> You can write > >> >>>> :- likes (Bob, baseball); > >> >>>> > >> >>>> but you cannot write > >> >>>> :- likes (Bob, :- exploration (space, :- or(rockets, solarsails))) > >> >>>> > >> >>>> The second example is a 3-level deep binary tree ... but is not > valid prolog. Of course, you can convert it into valid prolog, but then it > is no longer a single, deep tree, it would have to be three shallow trees. > >> >>>> > >> >>>> The game being played here is "how do you represent knowledge?" > and there's a whole rainbow of choices: trees and graphs and directed > graphs or undirected graphs or hypergraphs, .. or RDF or "semantic triples" > or datalog or json or tables, or whatever. And any one of these systems is > really enough for "anything" - you can represent knowledge with any of > these systems. > >> >>>> > >> >>>> The real questions become: How easy is it to use? For example, you > can represent "the green ball is under the couch" with "semantic triples" > but it becomes hard and verbose. Another example: you can represent a > hypergraph with just ordinary graphs, but how much extra RAM and CPU does > that need? If CPU and RAM were free, if it weren't for these kinds of > concerns, we could just layer datalog on top of Apache tinkerpop and use > graphQL and declare victory. > >> >>>> > >> >>>> --linas > >> >>>> > >> >>>>> > >> >>>>> ср, 18 авг. 2021 г. в 02:40, Linas Vepstas <[email protected]>: > >> >>>>>> > >> >>>>>> I spent the last week trying to convince a group of scheme > enthusiasts to build a "database for s-expressions", which, after all is > said and done, is all that the Atomspace is. This idea went over like a > lead balloon. > >> >>>>>> > >> >>>>>> The primary stumbling block seems to be conceptual. People can > visualize a database of rows and columns -- basically SQL -- very > conventional. They can visualize a database of key-value pairs -- > basically, noSQL. Also very popular. The idea of a JSON database is now > common enough. JSON is, after all, a nested, hierarchical key-value store, > having the form {name1:value1, name2:value2, ...} -- you can think of > name1, name2, .. as being like column labels, and (value1, value2, ...) as > being rows. The biggest difference between tables and JSON is that tables > are fixed-width, with fixed column labels, while JSON is free-form: every > JSON expression carries it's own labels. And, since it's hierarchical, > each value can be another JSON expression, nesting arbitrarily deep. It's > a labelled tree. > >> >>>>>> > >> >>>>>> When I suggested that one can store just plain s-expressions -- > i.e. just (value1, value2, ...) without the labels ... an unlabeled tree > ... this seemed to make people's heads explode. So my efforts, it seems, > were for naught. Perhaps I planted a seed, though. > >> >>>>>> > >> >>>>>> The goal of a generic, agnostic database of s-expressions is to > overcome the marketing problem the AtomSpace has. If some other > organization could explain to the world what that is, and provide agnostic, > generic API's, I think that would be a good thing. However, based on the > cold reception I got, I'm thinking it may take another 10 years before the > idea catches on. > >> >>>>>> > >> >>>>>> (The reception I got was "why don't you use JSON?" so I had to > explain the problem with the labels. Once that was clear, the next > suggestion was "why don't you use Prolog/Datalog?" I tried to explain how > prolog is limited to crisp true/false values, and how prolog does not > allow trees - it's not hierarchical the way s-expressions and JSON are - > but this argument did not seem to gain traction. Somehow, just saying > "it's a database of s-expressions" is not enough to convey the idea. > People stumble on this. And yet, that's all that it is...) > >> >>>>>> > >> >>>>>> I'm saying this out loud, right here, right now, because if you > are reading this, and you are thinking to yourself "I never quite > understood what the atomspace is" -- well, it's that. It's a database of > s-expressions. It's difficult to take the next step, until this first basic > idea becomes clear. I want this first, basic idea to become clear to > everyone. > >> >>>>>> > >> >>>>>> As to Hyperon -- Ben, I skimmed through everything written on > Hyperon, and it seems (to me) like it could be "easily" implemented within > the existing AtomSpace framework. I think this would be the right > direction to move in, but I don't think that is possible until there is > some sort of shared understanding about how things work, about how things > could work, about what needs to be done. Reaching that shared understanding > may require real work and hard thinking -- there's no magic wand of sudden > enlightenment -- but its doable. And it can be done with, ahhh talking and > email. I very strongly encourage discussion. Let the sun shine in. > >> >>>>>> > >> >>>>>> -- Linas > >> >>>>>> > >> >>>>>> On Tue, Aug 17, 2021 at 3:24 PM Ben Goertzel <[email protected]> > wrote: > >> >>>>>>> > >> >>>>>>> https://wiki.opencog.org/w/Hyperon > >> >>>>>>> > >> >>>>>>> On Tue, Aug 17, 2021 at 1:39 AM Amirouche Boubekki > >> >>>>>>> <[email protected]> wrote: > >> >>>>>>> > > >> >>>>>>> > Is there a page that gathers all the publications regarding > the new design ? > >> >>>>>>> > > >> >>>>>>> > -- > >> >>>>>>> > 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/CAL7_Mo_7ihMrRCZY%2BCLwAZ5KcHGqbRqwQgpOb8pLz1qY9Rj%2BSw%40mail.gmail.com > . > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> Ben Goertzel, PhD > >> >>>>>>> http://goertzel.org > >> >>>>>>> > >> >>>>>>> “He not busy being born is busy dying" -- Bob Dylan > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> 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/CACYTDBf8jVx8pxaiwvmvkf0ACJgqGQeF6X8s3E%3D%3DdXhr2sPCvA%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/CAHrUA34_UMZf-3t0giA7TZVQmXs%3DO2-aHB3sn5FC0o-6YBdzCg%40mail.gmail.com > . > >> >>>>> > >> >>>>> -- > >> >>>>> 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/CAFj%2Bw-sueAkJQaU1C0Ef4t60FrtFG3A%3DWQk-z%2BjSM56PQzE%3Dvw%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/CAHrUA37UtA8YZ4qrvFSYdkBSPEVZeUZP5wbyyqS8oA-3UZ4VJw%40mail.gmail.com > . > >> >>> > >> >>> -- > >> >>> 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/CAFj%2Bw-uc3Mnt1zFDwosk11AoM%2B%2BjkJsp_U-dtcEdHaxVR%3DtgUw%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/df24d2f4-ba28-44e9-975f-5ca09edc44a8n%40googlegroups.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 a topic in the > Google Groups "opencog" group. > >> To unsubscribe from this topic, visit > https://groups.google.com/d/topic/opencog/xQbA8_6Wg5w/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > [email protected]. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CAHrUA36k_9-PeZOvbwJ2Dtx5%2BE4M7pMsg-QF%3DA_BkCJvDCtzGw%40mail.gmail.com > . > > > > -- > > 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/CAER3M5mT0a6ni8eLPT9StSETOaB%2BpOgPDAx9jTgt6ELPHgFkJw%40mail.gmail.com > . > > > > -- > Ben Goertzel, PhD > [email protected] > > "My humanity is a constant self-overcoming" -- Friedrich Nietzsche > > -- > 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/CACYTDBcj_bW_t80KCC88iBGu%3DFPUo10Eg%2B%2BAKs%2BO-f7L8W3TBQ%40mail.gmail.com > . > -- 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/CAER3M5nSok4NG%2BkmvHoZ5g2JKdBE1-Ao5c9V%3DzdnT_xTnapt_A%40mail.gmail.com.
