Soar can incorrectly give i-support to wme's when encountering faux operator proposals

[GoogleCodeExporter]

If a production creates a structure that looks like an operator proposal but 
really isn't (for example if it's storing a past episode that includes a 
snapshot of a previous operator proposal), it may incorrectly give all of the 
rhs items i-support.  The reason is that it's test for an operator proposal is 
very shallow (the attribute name is "operator" and the preference is 
acceptable).  

One solution might to make sure that the operator that is being "proposed" is 
actually being added to a valid, current state and not some other data 
structure.

(line 5882 of rete.cpp is where this occurs.)

Original issue reported on code.google.com by maz...@gmail.com on 17 Dec 2012 at 9:31

[GoogleCodeExporter]

Could LTI's might make the above solution tricky?  I'm imagining a case in 
which the episode being recalled and copied has a faux operator proposal in it 
linked to a state with an LTI that is still on the state stack.  If that's even 
possible, the above solution might still not be able to determine that it's not 
a true operator proposal.

Original comment by maz...@gmail.com on 17 Dec 2012 at 9:39

[GoogleCodeExporter]

I think in the case described in comment 1, it's still a valid operator 
proposal. If there is a ^operator <o> + on the state, I think it should be 
treated as an operator proposal no matter what, even if the state also happens 
to be an LTI.

Original comment by marin...@gmail.com on 17 Dec 2012 at 11:27

[GoogleCodeExporter]

FYI, what you're describing is a specific instance of a more general problem 
where recalled LTIs get mixed with current LTIs. SoarTech has a proposed 
solution for this problem that we may start pursuing next month. (I was under 
the impression that this had already been discussed and approved by John, but 
if not, then we should do that).

Original comment by marin...@gmail.com on 17 Dec 2012 at 11:29

[GoogleCodeExporter]

Bob, are you're saying the case I described really is an operator proposal 
because, via the epmem recall or subsequent copy, it unintentionally re-creates 
the past operator proposal onto one of the current states?

Or to put it in seasonal terms, are you saying that a ghost of operators past 
is managing to become real?

Original comment by maz...@gmail.com on 18 Dec 2012 at 6:58

[GoogleCodeExporter]

I'm saying that I think the solution to this problem should center around not 
linking retrieved LTIs to current LTIs (and we have a proposal for how to do 
that). This solves other problems, and also doesn't require any special case 
logic for detecting operator proposals. In this approach, then, if there ever 
is a state that has an operator + augmentation on it, then that is an operator 
proposal, and the LTI status of the state or the origin of the operator + 
doesn't matter. 

Of course, this is contingent on our other solution actually working. If that 
doesn't pan out for some reason, then maybe special case logic will be 
necessary to handle the case you describe (although, if no one is having this 
problem, I'd wait to implement it, because maybe there's a clever use of epmem 
that actually takes advantage of this behavior somehow).

Original comment by marin...@gmail.com on 19 Dec 2012 at 12:36

[GoogleCodeExporter]

This issue should be resolved with the latest check-in.

Original comment by maz...@gmail.com on 5 Jan 2013 at 8:38

• Changed state: Fixed