Allow an I/O device to specify the efferent copy of a command

[jefft0]

When a Replicode program executes a(cmd ...), the program controller injects an "efferent" copy of the command so that it can be used in learning and reflection. The AERA design requires that the efferent copy should be a copy of the command which was actually executed by the I/O device, not the command ejected by the program and received by the device. For example, the program may eject a command to set a force of 20 to an actuator I/O device, but the actuator has a maximum force of 10. So, the efferent copy should have a value of 10. If the I/O device executes a requested command unchanged, then the code in the program controller is good enough.

The program controller calls the eject method which the I/O device overrides. To solve this problem. I suggest changing the eject method to return the command executed. The eject method can simply return the same requested command, or it can create and return a new command object of the actually-executed command. The program controller will make a fact of the command and inject it.

[thorisson]

I´m a bit confused by this statement: "Furthermore, when the program controller injects the efferent command, it assumes that the external environment doesn't. (But only the external environment knows what command is actually executed.)" I changed "external environment" to "IO device", but that may not reflect what was meant...

[jefft0]

I changed the proposal: Instead of eject returning a boolean true if it injects the efferent copy, it is cleaner to allow the program controller to inject the efferent copy. eject either returns the requested command or a modified command of what was actually executed. In either case, the program controller injects it.

[jefft0]

The I/O device can execute the requested command or a modified command. But there is a third case where the I/O device doesn't execute the command at all. I this case, we should not inject an efferent copy. What do you think?

[thorisson]

On 18 Oct 2020, at 15:14, Jeff Thompson ***@***.***> wrote: The I/O device can execute the requested command or a modified command. But there is a third case where the I/O device doesn't execute the command at all. I this case, we should not inject an efferent copy. What do you think?

I think it should always return with something when requested to act. In the case when it does nothing I would suggest it inject an efferent copy with a particular special value, e.g. ’nil’. (This could then be a way for an AERA agent to check if its IO devices are ‘live’ or not…) =K

[jefft0]

Responding with something makes sense. When the command executes normally, the efferent copy is something like (fact (cmd set_acceleration [c 10]) 100ms 200ms). What do you think of responding with the "anti fact" (|fact (cmd set_acceleration [c 10]) 100ms 200ms) meaning "There was no command in this time interval" ?

[thorisson]

oooh - yah great idea feels right =K

…

On Oct 18, 2020, at 19:58, Jeff Thompson ***@***.***> wrote:  Responding with something makes sense. When the command executes normally, the efferent copy is something like (fact (cmd set_acceleration [c 10]) 100ms 200ms). What do you think of responding with the "anti fact" (|fact (cmd set_acceleration [c 10]) meaning "There was no command in this time interval" ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[thorisson]

oooh - yah great idea feels right =K
…
On Oct 18, 2020, at 19:58, Jeff Thompson @.***> wrote:  Responding with something makes sense. When the command executes normally, the efferent copy is something like (fact (cmd set_acceleration [c 10]) 100ms 200ms). What do you think of responding with the "anti fact" (|fact (cmd set_acceleration [c 10]) meaning "There was no command in this time interval" ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

I wonder whether it should always inject an antifact when it does something different, along with what it did? - i.e. "I did not do this command which I received, but I did something different which is X..."?

[jefft0]

We now have two commits in the experimental branch where eject behaves as in pull request #125. I can't merge these commits into the master branch because we haven't merged the proposed pull request #125. So, I think we need to finish this design discussion so I can resolve the divergence. The last comment was from Kris:

I wonder whether it should always inject an antifact when it does something different, along with what it did? - i.e.
"I did not do this command which I received, but I did something different which is X..."?

This is not so straight-forward and is part of why I have been trying to clarify the semantics of "events" (and commands in particular). Currently the system does not have models that predict whether a command will be executed - a command is an "event" and it does not appear on the RHS of a model. The system injects the efferent copy of the command so that it can match the LHS of a model and make predictions about what the effects will be. If the system injects an anti-fact of a command, what are the operational semantics? What is the system supposed to do? For good reason, if a fact has an "anti-match" with the LHS of some model, the system does not try to infer anything from that.

[thorisson]

I don't think it needs to be complicated - it is simply a mirroring of whatever happens in the "real world" when something co-occurs with something else. So in this case the IO device simply posts an antifact of type I-DID-THIS (i.e. |ididthis) where the content is the original command, along with a fact I-DID-THIS where the content is what was actually done. Since this is timestamped it will enter AERA's memory just like any other set of events for which AERA can then create new models for. In other words, we assume that AERA builds models of its IO devices. (This would only be overridden by something in the seed, should we choose to do so.)

[thorisson]

Notice that it's not "the system" that is injecting the antifact, it's the IO device. I am assuming that we can have various such devices for any AERA agent -- which in itself may need to be clarified further, I admit. What also must be clarified is how an IO device knows that commands are directed towards itself. We may need to dissect the interview demo, which had at least two IO devices - speech and graphics. Maybe this can be done in the seed, through various means, like data type?

[jefft0]

I agree that the I/O device can inject a fact which says "I did this", and could also inject an anti-fact which says "I didn't do this" such as (|fact (cmd set_force [500]) 100ms 200ms) . But give me an example model that AERA would learn which uses this anti-fact.

[thorisson]

In theory AERA should be able to learn models that handle situations when something does not happen -- and thus is represented by an antifact. So this would in turn be an antifact on the LHS, e.g. along with a time computation of some sort. This way it could handle situations that involve e.g. a command and then something that did not happen, upon which something results from that (e.g. your mom getting angry because you didn't take out the trash even though she told you several hours ago). No?

[jefft0]

So, the anti-fact (|fact (cmd set_force [500]) 100ms 200ms) would be the LHS of the learned model. What, for example, would be the RHS?

[thorisson]

That could be anything, really… for instance, prediction that the agent forgot to check something (e.g. if the context for the model is that something doesn’t turn on when you press “go” is because you forgot to plug it in)…. =K

…

On 19 Apr 2021, at 08:17, Jeff Thompson ***@***.***> wrote: So, the anti-fact (|fact (cmd set_force [500]) 100ms 200ms) would be the LHS of the learned model. What, for example, would be the RHS? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMR6HMXJG3BTW7NOXYTFOLTJPRINANCNFSM4SSAOLEA>.