Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing buffer state checks #21

Open
asmaloney opened this issue Jul 30, 2023 · 7 comments
Open

Missing buffer state checks #21

asmaloney opened this issue Jul 30, 2023 · 7 comments

Comments

@asmaloney
Copy link
Contributor

(Related to #20)

According to the ACT-R manual, there are 5 checks one can do on a buffer (ACT-R manual pg. 229-230):

  • buffer empty
  • buffer full
  • buffer failure
  • buffer requested
  • buffer unrequested

From my reading of the pyactr code, it looks like only two buffer checks (empty & full) are supported.

Am I reading the code correctly? If so, does anyone know why the others were omitted?

(Context: asmaloney/gactar#221 )

@jakdot
Copy link
Owner

jakdot commented Aug 3, 2023

failure is also supported (as "error").

requested and unrequested checks are not supported. I'll have to check this in the manual to see if I could add them, thanks for pointing this out!

@asmaloney
Copy link
Contributor Author

My reading of the manual (quoted over here) is that buffer failure and state error are different queries.

Maybe in practice they result in the same thing though?

@jakdot
Copy link
Owner

jakdot commented Aug 4, 2023

Thanks, I see (thanks also for the comment in #20). I cannot think of how buffer failure and state error could differ from each other but I'll take a closer look. Also, if you discover any differences, please let me know. If they don't differ, it's trivial - I can add buffer failure which would have identical behavior to state error.

@asmaloney
Copy link
Contributor Author

Maybe buffer failure is a specific case of state error?

  • buffer failure: true if the failure flag has been set for the buffer and it does not hold a chunk
  • state error: true if the last request resulted in some sort of error

Also, from the visual-location section in the manual (pg. 357):

If there are no features which meet the constraints, then the buffer will be left empty, a buffer failure will be signaled, and an error state will also be set.

And visual buffer (pg. 369):

If there is no item there, then the buffer is left empty and the error state of the visual buffer is set and a buffer failure is indicated.

If we think of a generic module (not just declarative memory) - might there be other sources of error that you would set state error on? For example, say the module has some user input which fails. It's not a buffer failure, but the module is in an error state.

So for the declarative memory case, as implemented, it would be the same as there are no other sources of module error.

Aside: I find it an odd design decision in ACT-R that one queries the module state by giving the buffer name instead of the module. Any insight into why it was done this way? I think that really confuses things. I assume if a module has two buffers that querying state error on either of them results in the same thing?

@jakdot
Copy link
Owner

jakdot commented Aug 4, 2023

Thanks for the examples. If I get it right then buffer failure might be a more specific case, but so far from all examples it seems that whenever there is state error there is buffer failure and vice versa.

If we think of a generic module (not just declarative memory) - might there be other sources of error that you would set state error on?

Yeah, maybe ACT-R uses state error and buffer failure options to give the freedom to the modeller to distinguish the two cases, even though practically they seem to collapse to the same thing.

Aside: I find it an odd design decision in ACT-R that one queries the module state by giving the buffer name instead of the module. Any insight into why it was done this way? I think that really confuses things. I assume if a module has two buffers that querying state error on either of them results in the same thing?

I also find it an odd decision. And it also makes it non-trivial for pyactr implementation. pyactr currently only queries buffers, not modules (also for state) because it's the buffer, not the module, that the modeller specifies in their productionstring. pyactr gives modellers the options to connect more buffers to the same module and to create and name their own buffers. If I switch state error to modules I don't know how they should behave if there are more buffers tied to the module - but I could go for what you suggest, which in fact would distinguish buffer failure and state error.

@asmaloney
Copy link
Contributor Author

If I switch state error to modules I don't know how they should behave if there are more buffers tied to the module

In the more general case with multiple buffers, state error is only set if the last request resulted in some sort of error (according to the manual). So my understanding is that you could have buffer A in a full state, buffer B in a failure state and the module state would only be error only if the last request was to B.

I don't know if it applies or is helpful, but what I'm experimenting with in gactar is separating the two to make them clear. Something like this:

    match {
        goal [recall_list: nil nil ?list nil]
        buffer_state retrieval empty
        module_state memory free
    }

What I do internally is lookup the first buffer on the module and produce this code for ACT-R since it queries the module through the buffer (at least it says it does in the manual):

     =goal>
		isa				recall_list
		group			None
		element			None
		list			=list
		group_position	None
     ?retrieval>
		buffer	empty
		state	free

This is assuming that - if we had two buffers - querying on either of them for state error would give the same result since they are from the same module.

Essentially I'm trying to correct what I think is a confusion in ACT-R by making it explicit.

@asmaloney
Copy link
Contributor Author

One more tidbit I just ran across in the manual (pg. 520):

Any queries which the module will accept through the buffer, other than the default query of state which all modules must accept, need to be specified when the module is defined.

(emphasis mine)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants