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

[ghost]

From maz...@gmail.com on December 17, 2012 16:31:14

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: http://code.google.com/p/soar/issues/detail?id=127

[ghost]

From maz...@gmail.com on December 17, 2012 13:39:40

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.

[ghost]

From marin...@gmail.com on December 17, 2012 15:27:24

I think in the case described in comment 1, it's still a valid operator proposal. If there is a ^operator + 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.

[ghost]

From marin...@gmail.com on December 17, 2012 15:29:40

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).

[ghost]

From maz...@gmail.com on December 18, 2012 10:58:57

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?

[ghost]

From marin...@gmail.com on December 18, 2012 16:36:41

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).

[ghost]

From maz...@gmail.com on January 05, 2013 12:38:36

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

Status: Fixed