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

Unexpected behaviour from MaxInfoSelector #23

Closed
frankier opened this issue May 25, 2021 · 1 comment
Closed

Unexpected behaviour from MaxInfoSelector #23

frankier opened this issue May 25, 2021 · 1 comment

Comments

@frankier
Copy link
Contributor

I am a bit confused by the current behaviour of MaxInfoSelector. I would expect it to select the item with the maximum fisher information given the current ability estimate, however it seems to instead select based upon where individual item response functions reach their maximum, ignoring the differences in scale on the y-axis between them . See e.g.:
Screenshot from 2021-05-24 22-38-31

(Figure taked from A Visual Guide to IRT https://www.metheval.uni-jena.de/irt/VisualIRT.pdf )

Imagine there is a small distance on the x-axis between the peaks of the blue and the black curve. If I have an ability estimate at the peak of the black curve I would expect the next item chosen by MaxInfoSelector to be the blue one since it still has higher information even a bit away from its peak.

Basically, the behaviour I want is equivalent to RandomesqueSelector(bin_size=1) (which is what I've now moved onto --- temporarily at least) but the behaviour I actually get for the 2PL model is the same as UrrySelector.

What is the specification for MaxInfoSelector? The citation given is Lion 1977, but in that article there are no equations. If the current behaviour is the intended behaviour, maybe the documentation could make it clear since it's a bit surprising based on the current name/doc to me.

douglasrizzo added a commit that referenced this issue May 28, 2021
@douglasrizzo
Copy link
Owner

Thanks for catching that. The behavior you want is what the selector should do, but is not doing. I believe the commit above as well as 9d26df2 should solve that.

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