o-supported operator augmentations placed via tie ^items not persistent

[GoogleCodeExporter]

Description From Sam Wintermute 2009-07-08 18:32:09 (-) [reply]
An agent has a tie impasse, and tries to evaluate each operator. It goes 
into a
subgoal from the tie to do this (for each operator), which augments the 
^item
with an o-supported evaluation number. In the tie impasse, those numbers 
are
compared to generate superstate operator preferences (to resolve the tie).

Once superstate preferences are in place, the tie resolves, but as this is
happening, the evaluation numbers (which were on the tie ^items, and hence 
also
the superstate operators) are removed from WM for some reason, even though 
the
trace shows they have o-support. This causes the preferences to go away, 
the
tie reforms, and it all repeats.

To recreate, source the attached file, then
watch 5
step 5
run 6 --e

run 1 --e will now cause this:
--- propose phase ---
<=WM: (37: O1 ^value 2)
<=WM: (46: O2 ^value 1)

which is incorrect

A few waves earlier, the correct preferences are there:
(starting again from the beginning)
step 5
run 3 --e
pref o1 value

Preferences for O1 ^value:

acceptables:
  (O1 ^value 2)  :O 

but another wave shows this:
run 1 --e
--- Firing Productions (IE) For State At Depth 2 ---
--- Change Working Memory (IE) ---
<=WM: (15: S2 ^reward-link R2)
<=WM: (13: S2 ^type state)
<=WM: (14: S2 ^superstate S1)
<=WM: (16: S2 ^attribute operator)
<=WM: (17: S2 ^impasse tie)
<=WM: (18: S2 ^choices multiple)
<=WM: (19: S2 ^quiescence t)
<=WM: (20: S2 ^item O2)
<=WM: (21: S2 ^item O1)
<=WM: (22: S2 ^item-count 2)
pref o1 value

Preferences for O1 ^value:

(nothing else is printed)

Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 5:15

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

• Added labels: Imported-Bugzilla

[GoogleCodeExporter]

I ran into this again, but I now think that this isn't actually a bug. I wasn't
considering that WME support can differ based on the goal level. The WME here 
has
o-support in the subgoal, but no support at top-state. The file didn't actually 
get
attached, but the WME in question got a justification for i-support in the 
top-state
in addition to another for o-support in the substate. The top-state 
justification
immediately retracted, though, leaving it with just o-support in the substate, 
and
_no_ support in the top-state. So once the substate goes away, the WME does too.

Its sort of counterintuitive, since it is possible to match a WME through a 
subgoal
for which it has no support, but it makes sense if you think of a WME as having
support that is the superset of its support at all levels to which it is linked.

It would be helpful if the preferences command was more explicit about this, and
showed what support a WME has at each level it is linked to.

Original comment by sam.wint...@gmail.com on 30 Sep 2009 at 11:08

• Changed state: Invalid