sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

result structure gets incomplete support #139

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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, ....

Original issue reported on code.google.com by marin...@gmail.com on 29 May 2013 at 6:15

Attachments: