Issue 139 in soar: result structure gets incomplete support

[so...@googlecode.com]

Status: New
Owner: maz...@gmail.com
Labels: Type-Defect Priority-Medium

New issue 139 by marin...@gmail.com: result structure gets incomplete
support
http://code.google.com/p/soar/issues/detail?id=139

Attached is a simple Soar program that drops into a substate and then
returns a result structure (^foo.bar ran) to the superstate.

There are two substate apply rules (with the same name). The first one is a
standard apply rule that directly creates the result structure. This works
as expected -- the substate goes away and the result structure remains. (To
see this, reorder the applies so this one comes second, or comment out the
other one -- they have the same name.)

The second one tries to be clever and uses a description of the result
structure on the operator to create the result. It does this by firing
twice in parallel. In this case, when the substate goes away, the ^foo part
stays, but the ^bar ran part retracts. Looking at the justifications, only
the ^foo part is included in the justification.

I suspect that, because the rule fires twice in parallel, that the
instantiation that creates ^bar ran is local to the substate, and thus only
o-supported wrt the substate. The ^foo part is a proper result that just
happens to have ^bar ran as substructure (but that substructure was not
actually returned as a result). So Soar does not recognize ^bar ran as a
result, and it retracts with the substate.

Laird comments:

I took a quick look. This looks to be a race condition, where it creates
(F1 ^bar ran) in parallel with the creation of (S1 ^foo F1). When these two
are created in the same rule, Soar is smart enough to look for the
connection between them, but since this is happening in rules firing in
parallel, it is not smart enough to examine all of the parallel actions
(that create other preferences) and notice that F1 is now in the closure of
S1, so (F1 ^bar ran) should be a result. As you can imagine, doing this
right would require it to do some extra processing (multiple passes through
all of the preferences to chain through dependencies) that I'm sure Soar
isn't doing. So, yes it is a bug, ....

Attachments:
test.soar 835 bytes

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings