Propagators and ocaps

[Christopher Lemmer Webber]

I'm continuing a bit from this conversation:

https://groups.google.com/g/cap-talk/c/Rye8xI1TSnU/m/1g03OG5tBAAJ

I've mentioned that I've been making progress with Propagators on top of
Spritely Goblins. I haven't published it yet, but I am thinking of
naming this implementation "Spritely Brainy", so that finally we can
know we have a brain in a vat. (Whether the brain itself knows is
another question.)

If you are interested in propagators, here are three good resources:

- This talk by Gerald Sussman: "We Really Don't Know How to Compute!"
It's about several things, but especially propagators:
https://www.youtube.com/watch?v=Rk76BurH384

- The most current iteration of propagator design comes from Alexey
Radul's dissertation, which makes the advancement in having
propagators not only supporting complete values, but accruing
*partial* non-contradictory information about a value:

http://web.mit.edu/~axch/www/phd-thesis.pdf

- To really see what you can do with this, Leilani Gilpin's
dissertation "Anomaly Detection Through Explanations" seems a really
interesting resource (which I have only skimmed so far, but plan to
read fully):

https://groups.csail.mit.edu/mac/users/gjs/lgilpin-PhD-EECS-Sept2020.pdf

So, why should we care about propagators?:

- Alexey demonstrates how propagators are the generalization of several
kinds of programming systems in his dissertation: logic programming,
functional reactive programming, constraint solvers including type
inference, rule-based systems, and even probabalistic programming can
all be nicely implemented on top. (Except that propagators sometimes
even seem to do better than the present approaches: for instance, in
FRP-on-propagators as Alexey describes it, cycles in the graph are no
problem!)

- Propagators and the cells they talk to can be both easily modeled on
top of "classic actors", making them a good fit for current ocap
systems. (Here's one example: deliver your witness testimony to the
capability that writes to this cell and then the propagtor-detective
will account for it!)

- The mechanism that Alexey describes in his dissertation for
propagation can be easily modeled on top of a "vat churn", which both
Agoric and Spritely Goblins have tooling for (ie, run local message
sending in the network until quiescence)

- Partial information is considered still useful. If we can narrow a
range of possibilities, that might be useful to know and query... it
might give us clues about which areas we should do more searching and
what we shouldn't bother with.

- It's possible to see *where* in a propagator network recursion might
occur, and even limit the amount of search space easily, helping
mitigate some of the "uncanny valley" aspects of logic programming
that MarkM has mentioned (I think)

- Alexey's version of propagators allow for propagation of the
*sources* of where corroborating information comes in, along with
with truth maintenance systems which allowing exploring different
worldviews. This can be done manually by the programmer.

- But it can also be done automatically! Set up an "ambiguity
operator" propagator which auto-explores the consequences of
different worldviews, and can even make note of which combinations
are contradictory so it doesn't re-explore those accidentally.

- I believe the space of exploring explainable AI is worthwhile, *even
if not possible to be perfect*, for the same reasons that it is
worthwhile for humans to do their best to explain themselves, even if
they are not perfect.

Since these compose well with present exploration of ocap systems, and
propagators are fairly easy to build once the core ideas are known, it
seems worthwhile for us to add them.

There is more to say. But perhaps I should get my implementation of
Brainy out there so I can say it better.

- Chris

[Terry Hayes]

Chris,

I may have mentioned this before, but Edward Kmett has done quite a bit of work on propagators (in Haskell). 

https://www.google.com/search?q=edward+kmett+propagators

Terry

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/871rdv65sc.fsf%40dustycloud.org.

[Bill Frantz]

On 2/4/21 at 1:34 PM, cwe...@dustycloud.org (Christopher Lemmer

Webber) wrote:

>- This talk by Gerald Sussman: "We Really Don't Know How to Compute!"
>It's about several things, but especially propagators:
>https://www.youtube.com/watch?v=Rk76BurH384

Strange factoid. He started computing on the same IBM 650 at
Columbia University that I did. Same year, 1961, too.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz | Airline peanut bag: "Produced | Periwinkle
(408)348-7900 | in a facility that processes | 150
Rivermead Rd #235
www.pwpconsult.com | peanuts and other nuts." - Duh |
Peterborough, NH 03458

[Christopher Lemmer Webber]

Hey Terry, thanks.

The "lattice variables" bit mentioned in the summary on
https://www.youtube.com/watch?v=s2dknG7KryQ sounds promising. I'll try
to find some time to watch.

[Christopher Lemmer Webber]

Bill Frantz writes:

> On 2/4/21 at 1:34 PM, cwe...@dustycloud.org (Christopher Lemmer
> Webber) wrote:
>
>>- This talk by Gerald Sussman: "We Really Don't Know How to Compute!"
>>It's about several things, but especially propagators:
>>https://www.youtube.com/watch?v=Rk76BurH384
>
> Strange factoid. He started computing on the same IBM 650 at Columbia
> University that I did. Same year, 1961, too.
>
> Cheers - Bill

Fun! Did you have the chance to know each other at the time?

[Bill Frantz]

On 2/4/21 at 11:01 PM, cwe...@dustycloud.org (Christopher

I don't remember him, but it was a long time ago. I was in a
program for High School students called the Science Honors
Program. There were groups that built an electron microscope,
did some biology stuff, and of course, one that learned computer
programming. I'm probably leaving some important things, like
chemistry, out.

Our computer programming course started with machine language on
the IBM 650. This machine was internally decimal, so we didn't
need to convert numbers for simple problems. It has 10 digit
words, with 2 digit op codes and two 4 digit addresses. Most
instructions had an operand address and the address of the next
instruction. This layout permitted optimization of programs by
placing the next instruction where it could be quickly read from
the rotating drum memory.

After we did a machine language exercise, we were introduced to
the idea of an assembler, with a program called SOAP -- Symbolic
Optimizing Assembly Program. It did the drum layout.

We also did a program in ForTransit, a card-based, 4 pass
Fortran. It only permitted maybe 20 characters of the source
code on each card, because the card had to be run with a plug
board that separated the punches in each column of the card
because the computer couldn't read the special characters otherwise.

We then moved on to the IBM 1620, which had transistors instead
of tubes, and magnetic core memory.

We have it easy now.

Cheers - Bill

----------------------------------------------------
Bill Frantz | Art is how we decorate space,
408-348-7900 | music is how we decorate time.
www.pwpconsult.com | -Jean-Michel Basquiat

[Christopher Lemmer Webber]

Cooooool.

We do have it quite easy now but I love hearing about old systems and
wish I had more low-level experience than I have. Oh well... I seem to
be getting by mostly okay in abstractlandia I guess.