How to model additional constraints?

[asmaloney]

In ACT-R, we can add constraints (they call them modifiers) to tests like this:

   =visual-location>
     isa        visual-location
   > screen-y   500
   < screen-y   520

From the manual:

When testing slot values in conditions and checking queries in a production there are several modifiers which can be used: =, - , <, >, <=, and >=. ... The inequality tests (<, >,<=, and =>) can only be used when the values are numbers (the test fails if either of the elements being tested is not a number).

How should we model these in amod?

Because we are using our own mini-language-within-a-language to parse the matching, we need to fit it in there somehow. So this might be messy.

Maybe something like:

// chunk defined as [visual-location screen-x screen-y color]

visual-location [visual-location: * (?screen-y > 500 & ?screen-y < 520) *]

// or

visual-location [visual-location: * (?screen-y > 500 & < 520) *]

// or

visual-location [visual-location: * ?screen-y *]
           when (?screen-y > 500) and (?screen-y < 520)

(Now that I've written them out I think I'm partial to some form of the last one for readability.)

Also note that with this we can simplify our current solution and make it more readable:

goal [isMember: ?obj1 ?cat pending]
retrieval [property: ?obj1 category ?obj2!?cat]

// would become:

goal [isMember: ?obj1 ?cat pending]
retrieval [property: ?obj1 category ?obj2]
     when (?obj2 != ?cat)

How do we translate it to the different frameworks?

I think ACT-R & pyactr should translate directly, but ccm is different and I don't see how this kind of thing is supposed to be handled.

Does anyone have an example of something like this from ccm?

[NoTime4Inertia]

This is a bit of speculation:

goal [isMember: ?obj1 ?cat pending]
retrieval [property: ?obj1 category ?obj2!?cat]

I am assuming this is for the buffer to match in a production? (eg. match {goal ... retrieval... })

// would become:

def firstProduction(goal='?obj1 ?cat pending', retrieval='property:?obj1 category:!?cat'):

I am unsure this is an accurate translation. The steps to execute will be placed in the function under this line, which will be where you set the next goal to match in later production(s).

I have no idea if this was helpful. If not, my apologies.

[asmaloney]

Yes, thanks. That part is already implemented and works.

chainCategory {
    match {
        goal [isMember: ?obj1 ?cat pending]
        retrieval [property: ?obj1 category ?obj2!?cat]
    }
    do {
        set goal.object to ?obj2
        recall [property: ?obj2 category *]
    }
}

becomes:

    # amod line 76
    def chainCategory(goal='isMember ?obj1 ?cat pending', retrieval='property ?obj1 category ?obj2!?cat'):
        goal.modify(_1=obj2)
        memory.request('property ?obj2 category ?')

I was pointing out that the way it's done now in gactar with ?obj2!?cat can map to a new "when"-style and be a lot more readable.

The question is, if I want to implement:

someProduction {    
    match {
        // ... other matches
        visual-location [visual-location: * ?screen_y *]
           when (?screen_y > 500) and (?screen_y < 520)
    }
    do {
        // something with ?screen_y
    }
}

What should ccm do? How would I normally implement that kind of constraint?

[NoTime4Inertia]

To get this to work, I had to import random and add the following to the previous production:

i = random.randint(450,550)
if i > 500 and i < 520:
    goal.set('next')
else:
    goal.set('finish')

I can't seem to figure out how to get a buffer to hold anything that isn't a string and AFAIK it can't, even though buffer.py seems to suggest key:value pairs are able to hold non-string values.

[asmaloney]

Ah thanks. If it just uses Python and it's not part of the matching that might be a problem.

Maybe @rlwest or @tcstewar can shed some light on it?