On Thu, May 30, 2019 at 3:25 PM buj <[email protected]> wrote: > Upon further study, I have become quite confused on atomspace's type > system. Let me explain: > > I was on my quest to understand which links are executable, and which are > evaluatable. So I came across various resources: the scheme command > cog-get-subtypes, the "type hierarchy definition file" > <https://github.com/opencog/atomspace/blob/master/opencog/atoms/atom_types/atom_types.script> > and > the "folder where (all) atom types are implemented" > <https://github.com/opencog/atomspace/tree/master/opencog/atoms>. I see > that the type hierarchy is completely separate from the actual definitions > (C++ implementations) of the types, so I assume that it is the user's job > to be faithful to the hierachy---if I define a type to be a subtype of > EvaluatableLink, then it should be evaluatable, and I (as a programmer) am > responsible for implementing this feature. >
Yes. Now, the problem is, a lot of the types do not meet these standards... > concretely, there are many subtypes of EvaluatableLink which are not > evaluatable (in the cog-evaluate! sense): > > - SatisfyingSetLink, MemberLink, SetLink > > These do not seem to need C++ classes behind them, because they "don't do anything". > > - some CrispOutputLinks: > - ExistsLink, ForAllLink, > > These are legacy types; they are not used, at all. No one is implementing the sigma-pi Borel hierarchy in the atomspace. It seemed like a cool idea a decade ago, and they've mouldered ever since. They should probably be removed. To answer you question more generally: In the beginning, none of the atom types were backed by C++ classes. None, that is, except for Atom, Node and Link. But then BindLink got invented, because it needed to hold a cache of pre-compiled state. So it got a C++ class. And then, one-by-one, reasons were found to add other C++ classes to sit behind certain other atom types. Historically, atoms were not "active objects", i.e. did not have methods on them. Other code "did stuff to them" (did stuff with them) It slowly became obvious that it would be better if that external code got migrated into methods on the C++ classes. This is an ongoing, slowly moving project. Slowly moving, because its not always obvious what the right implementation is. And its not urgent, since mostly "things work ok as-is". Based on natural use, there seemed to be some atoms that, when "executed", would naturally return an Atom as a result. Others seemed to naturally return a truth value. Thus, the distinction between "evaluatable" and "executable". In the last few years, it became apparent that this distinction is perhaps bogus, so there is another very slow move to erase the distinction. It cannot be instantly or easily erased, because there are a bunch of theoretical questions, the answer to which are not clear. Any technical decision like this has side-effects, and its hard to anticipate them. So we grope in the dark, feeling around, trying different designs to see if they feel comfortable or not. The new wiki page https://wiki.opencog.org/w/AtomSpace#Overview lists 10 bullets in the overview section. The actual C++ code is trying to implement all 10 of them, all at once, even-handedly, without tipping over too far one way or another. Its a hard balancing act. > - PresentLink. > - And also AbsentLink, which is a subtype of PresentLink (why?). > > Simpler than having an abstract base class "PresentOrAbsentLink" Its already hard to explain all of these; creating bogus base classes just further confuses things. I need to understand why there exists such a disparity. (And also what > guarantees the type system provides.) > I hope the above answers your questions. Is it merely because these features were "not in demand"? Or am I missing > something bigger/different here? (For many of the links---such as > ExistsLink, ForAllLink, > There is nothing at all obvious about those two. They are good examples of highly non-trivial, non-obvious links. They make delicate statements about the nature of infinity -- or rather, about countable and uncountable infinities, or rather, the infinite number of infinities. They're not implemented because -- no one is doing set theory in the atomspace; set theory is a very arcane, obscure and difficult branch of mathematics, and I don't currently see any relevance at all to AI/AGI. Its like topoi, or pointless topology - interesting, certainly, but with no direct bearing that I can see. Alternately, you could argue that we need ExistsLink, ForAllLink in order to implement first-order-logic, second-order-logic, HOL. or wait .. lets do agda! Another slippery slope. We do not currently have a functional, crisp-boolean true/false first-order theorem prover for the atomspace. Baby steps .. when someone needs this/wants this .. they can work on it ... PresentLink, AbsentLink---the implementation seems obvious from an outside > perspective/at first glance. > Hah hah. Two weeks ago, I sat down and rolled up my sleeves, and said to myself: "today is the day I implement AbsentLink as a C++ class". It's even mentioned in a comment in a recent commit. After laying the groundwork for this, I realized that it was impossible. Well, maybe not impossible, but very complicated and confusing, to the point that it seemed like a recipe for failure and wasted effort. A classical "bad idea". So I gave up. > Though what could possibly "evaluating a SetLink" mean? ...) > Oh! That's easy! Evaluate all of its members. I am on the verge of actually implementing that. I haven't, for two reasons: 1) no one is asking for this. There's no obvious need for it. 2) Different external theories might have their own distinct reason/answer to that question. For example, PLN states that one should use this-and-such formula to compute the resulting "average" truth value. But textbook Bayesian probability theory wants to supply you with a similar, but slightly different answer. And a neural net may want to provide yet another answer ... this is why Values exist (to accommodate all these theories), and it is also why "external code does things with atoms", instead of atoms having methods to do things. The C++ classes do not have a "Bayesian-probability" method, and a different "neural-net method", etc. ... on down the line. 3) Turns out SetLinks are evil. Who knew? Took years to figure this out, and not everyone understands yet. See the wiki page for SetLinks. -- Linas -- cassette tapes - analog TV - film cameras - you -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA3521zp2cKL0ydEhuzb11Rc7JowcuVbPB_AYKW0jnM8vhw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
