future of atomese

[Ben Goertzel]

OK -- I see the light now ...

What we need to do is

1) make a surface syntax for Atomese that is effectively like Agda,
but a good bit prettier

2) make an ultra-fast type checker that encompasses moderately complex
dependent types

3) then instead of using slow Agda, and incurring the overhead of
going Agda ==> Haskell ==> C++ ... we just go straight NewAtomese ==>
C++, and everything is fast as well as elegant (well everything except
the slow things actually happening inside OpenCog...)

... in line with the general principle that integrating others' ideas
sometimes ends up working better than integrating their code...

But ... well ... not this month I guess ;)

ben

--
Ben Goertzel, PhD
http://goertzel.org

Super-benevolent super-intelligence is the thought the Global Brain is
currently struggling to form...

[Linas Vepstas]

Hi Ben,

I don't quite see where you are going with this.  Let me re-iterate some random unstructured thoughts that I've said before, and see where they might fit in.  Like riffing on a melody.

* First, I'd rather not have human being program in atomese -- I kind of wish it really was a knowledge-representation substrate, and some kind of learning algorithms would generate and manipulate atomese.

* I do admit that, when human beings do code in atomese, a nicer syntax, or something would be nice. Earlier today, I explained to David DeMaris that one can create timelines in atomese just fine (using ParallelLink, JoinLink and SleepLink) but if you want it to pause (sleep) for random amounts of time (e.g. using RandomLink) then programming gets awkward. Doable but awkard.

* But what's the point of hand-written snippets of atomese, anyway? The goal was to have automated learning algos manipulating the graphs and the automated algo might have a really hard time understanding some complicated RandomLink with math in it. ... so why are we doing this?

* The nice thing about types and type theory is that type-checking programs are gauranteed to terminate in finite time, always. This is a useful property that we currently do not leverage in atomese.

* Type-checking terminates because, in the theory of term rewriting, type checking is .. I forget... strongly confluent, or something like that.

* Term re-writing is exactly what we want to do, when converting EvaluationLinks into PredicateNodes, or converting between various forms in the EquivalenceLink. We don't have any architected way of doing this.  The chainer and threign beaste pln rules seem to do this in some ad-hoc ways.  I think you call them "rules" in PLN, but there's no C++ code or API that I can call to answer the question "here's a graph, do we already have an equivalent graph somewhere in the atomspace?"  (for example, by tracing through EquivalenceLink)

* I am concerned by the excessive obsession with lambda calculus and the already heavy over-use of LambdaLink.  Down that way leads madness.  We need to spend a lot more time thinking "term re-writing" and a whole lot less thinking "lambda"  -- and this does seem to fit with some sort of AGDA-vision, because proofs are kind-of-ish about term re-writing, and about termination. 

* Which brings me back to Kripke Semantics and possible worlds. I have no clue how AGDA does it's stuff, but, in the "real world", with probabilistic reasoning, I just don't see any way at all of avoiding the need for possible worlds during the exploration of a proof.

* And so, creating a system for managing possible worlds during proof exploration seems to be an important, neglected task. (I'm not sure, I sometimes suspect that what you used to call "inference trails" is a similar-but-different idea).

* So, the thing that we really need, is not so much a nice surface syntax for atomese, but a nice surface syntax for inference control.   Let me explain: right now, PLN goes off and explores in some random direction, and promptly hits a combinatorial explosion and all is lost, and so you invent ECAN to place some reins on this beast.   But ECAN is this opaque automated system, and we can guess at what it might be doing, but its hard to visualize, and maybe its doing the right thing, and maybe its not.   So I'm thinking -- lets make inference paths -- the sequence of steps taken during a search for a proof -- lets make that explicitly visible, a first-class object that can be seen and manipulated and explored.  Something that can be pruned, or allow to grow, like a good gardener tending a plant: Lets watch the many shoots of inference, and see which seem good and which bad, and then design an automated system to rein in, to control the directions in which inference goes.  

* The problem that I see with agda, and with haskell, is that they go off and pursue proofs on their own, with no visibility to the programmer about what they are doing.  Trust the system. haskell is infamous for having performance that is hard to predict: you look at haskell code, and you can't tell quite how long it might take.  So, I'd like to have "visible inference" (in PLN, using kripke semantics) so that we can have ECAN or its follow-ons can "watch PLN think" -- stay focused, stay on track, not get overwhelmed by combinatoric explosion.

--linas

--
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 opencog+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
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/CACYTDBdDBfi%3DSSnvRpixtsL_AqRu75AxZbX%2BAN9UkdLZAZHX2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Goertzel]

About inference control, see attached poster paper, which I gave at
AGI-16 but for some reason haven't posted online yet.... This is my
idea how to express inference control heuristics elegantly and
concisely in terms of (an odd sort of) probabilistic programming...

About possible worlds: yes, this requires more thought.... Matt and
I wrote a paper on how to derive possible worlds semantics (of an odd
sort) from experiential semantics, essentially by subsampling...

http://agi-conf.org/2010/wp-content/uploads/2009/06/paper_55.pdf

I have to think more about how to express how this all fits together...

ben

>> email to opencog+u...@googlegroups.com.

>> To post to this group, send email to ope...@googlegroups.com.
>> 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/CACYTDBdDBfi%3DSSnvRpixtsL_AqRu75AxZbX%2BAN9UkdLZAZHX2A%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> 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 opencog+u...@googlegroups.com.

> To post to this group, send email to ope...@googlegroups.com.
> 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/CAHrUA37FfTWoq7nh3wu3TmOYTd9rH30qP1ZAs5wZPABJJs-yow%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Nil Geisweiller]

On 08/30/2016 04:41 AM, Linas Vepstas wrote:
> * So, the thing that we really need, is not so much a nice surface
> syntax for atomese, but a nice surface syntax for inference control. Let
> me explain: right now, PLN goes off and explores in some random
> direction, and promptly hits a combinatorial explosion and all is lost,
> and so you invent ECAN to place some reins on this beast. But ECAN is
> this opaque automated system, and we can guess at what it might be
> doing, but its hard to visualize, and maybe its doing the right thing,
> and maybe its not. So I'm thinking -- lets make inference paths -- the
> sequence of steps taken during a search for a proof -- lets make that
> explicitly visible, a first-class object that can be seen and
> manipulated and explored. Something that can be pruned, or allow to
> grow, like a good gardener tending a plant: Lets watch the many shoots
> of inference, and see which seem good and which bad, and then design an
> automated system to rein in, to control the directions in which
> inference goes.
>

I totally agree with that. Actually the forward chainer creates traces
of inferences in the AtomSpace as ExecutionLinks relating rules, sources
and output targets.

The next step is to mine these traces and use observed patterns to
improve inference efficiency. This could be done on-line (as the
inference takes place) or off-line. It's not holy clear to me how we're
gonna use that knowledge to drive inference control, but I guess we can
go incremental, like tweaking the hebbian links so that ECAN does a
better job, these hebbian links can also be linked to rules, they can be
contextualized, etc. I think there's a lot of meta-learning that can
take place just by tweaking the hebbian links. The challenge is gonna be
to be able to keep under control the computational power allocated to
meta-learning into order to speed-up learning.

I didn't mention SampleLink but I should have, here I have.

Nil