Deferred ops

[Robert w]

Hello,

I am calling what Pei is called a "operator" an op for my reasons.

what do I mean with deferred ops? Simply that the end of the execution doesn't happen in the same cycle as the invocation of the op. This is always the case for 'normal' ops.

Why is this a problem? Sometimes a system has to be able to start a process and be able to track the state of the processing without starting the same process again or restarting it, even in the absence of 'signaling' events which indicate the success/end of the op.

The reasoner can resort to working memory when such a signaling makes sense.

ex:

<(Aevent, ^op, DONEevent) =/> G0>.
here the nature goal system can wait for DONEevent by detachment when ^op was completed and event ^op was injected into the system.

But how to handle the case when such an event isn't available for reasons or when it doesn't make sense to inject events like DONEevent because the events can be easiliy get confused?

I came up with the idea to postpone the processing of the detached goal when the processing of op is still in progress.

This is currently implemented in my implementation as a flag of the op. processing of the detached goal is postponed until the op is completed (it's as if the goal isn't there for the rest of the nature goal system).

Here is a table to indicate the different types of invocation of a op.

https://gist.github.com/PtrMan/a6397389698430495bca14eab01b533d

I am open for any ideas or suggestions how to handle this in a better more correct way.

-

Rob

[Pei Wang]

Hi Rob,

I basically agree with your analysis, though I suggest a slightly different solution.

Unlike many AI systems where each event is associated with a time interval for its occurrence, in NARS the time attribute of an event E is a point (or processing cycle, to be accurate) where its truth-value is evaluated. When there is no other information, this truth-value can be projected to nearby moments, without an explicit indication of the interval in which E occurs.

Therefore, a compound event (E, F) should be understood as "E is evaluated as happening, then F is evaluated as happening" with an unspecified time interval between these two moments. It does not say that E ends before F starts, as you pointed out. However, this type of compound can be used to indicate the boundary of an event, as (--E, E) indicates the event when E isn't the case (using "--" for negation), then it is, which is a way to indicate its beginning. Similarly, the end of E can be represented as (E, --E).

Operation ^op(arguments) is a special type of event, in that (1) it is directly realizable by the system itself, and (2) its time attribute indicates its starting point, i.e., then the operation is invoked. On the other hand, its ending is an ordinary event observed by the system. Using the above idea, it can be represented as (^op(arguments), --^op(arguments)). Therefore, to stress that the second operation cannot start until the first one ends, it is (^op1(arg1), --^op1(arg1) , ^op2(arg2)). In your example, it will be <(Aevent, ^op, --^op) =/> G0>, roughly speaking. Please note this is not always needed even if the operation takes multiple cycles, because =/> also corresponds to an unspecified time interval, not exactly the next cycle.

In summary, I agree that it is sometimes (though not always) necessary to indicate the ending of an operation (or an event in general), though I don't think it is a good idea to introduce special terms for that purpose. We can try both approaches to see which one works better.

Regards,

Pei

Virus-free.www.avast.com

--
You received this message because you are subscribed to the Google Groups "open-nars" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-nars+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-nars/bb7855fa-0324-4aa5-a122-f959ebde73c8n%40googlegroups.com.

[Adrian Borucki]

It feels like your interpretation of operations is not quite correct — they are not subroutine invocations strictly speaking, just signals for some other component of the system to do something. There is no “blocking” happening on NARS side.

Now, there is a challenge of how to combine the ability to execute complex plans / actions with the capacity to suspend / interrupt them when something unexpected happens. The naive way to do this is to just execute the first atomic step of the plan and re-plan again but that’s inefficient.

This requires some mechanism that can track the execution of foreign code, interrupting it if needed. Coroutines feel natural for that purpose but I’m not sure what’s the optimal solution. The trigger for interruption would possibly not come from NARS even, rather from some simpler external component that just monitors the environment for trouble. Of course all the normal events would get sent to NARS for processing still, the difference being that on those time steps you don’t ask it for any operations. Such implementation would make things run faster as well, as you don’t constantly ask NARS what to do — I think that’s generally a wasteful overuse of a system that is necessarily quite resource-expensive, considering its power.

Adrian