I have a matrix which I'm trying to run through the mirt function of the mirt package:

resp.freq <- data.frame(matrix(c(11, 46, 12, 31, 13, 8, 21, 20, 22, 68, 23, 12,
                                 31,  1, 32, 12, 33, 11), nrow = 9, ncol = 2,
                               byrow = T))
dados3 <- matrix(rep(resp.freq$X1, resp.freq$X2), ncol = 1)
dados3 <- data.frame(cbind(as.numeric(substr(dados3, 1, 1)),
                           as.numeric(substr(dados3, 2, 2))))

m1 <- mirt(dados3, 1, D = 1, SE = TRUE)

I used to run this through mirt 0.5.0 and would get the following end results:

        a1    d1     d2
pars 1.913 0.633 -3.152
SE   0.228 0.181  0.322

        a1    d1     d2
pars 1.659 1.121 -2.488
SE   0.200 0.190  0.261

However, my workstation has been updated and on mirt 1.2.1 and now I get the following output upon running m1 <- mirt(...:

Iteration: 1000, Log-Lik: -387.670, Max-Change: 0.00007
EM iterations terminated after 1000 iterations.

Calculating information matrix...
Warning message:
In loadESTIMATEinfo(info = info, ESTIMATE = ESTIMATE, constrain = constrain) :
  Negative SEs set to NaN.

And coef(m1) gives me:

            a1    d1     d2
par     11.515 2.732 -13.98
CI_2.5     NaN 0.685    NaN
CI_97.5    NaN 4.778    NaN

           a1    d1     d2
par     1.099 0.903 -2.139
CI_2.5  0.712 0.561 -2.611
CI_97.5 1.485 1.245 -1.668

        MEAN_1 COV_11
par          0      1
CI_2.5      NA     NA
CI_97.5     NA     NA

I've read the changelog, but couldn't find a reason for the behavior change. I've tried desperately changing the parameters of mirt(), but couldn't reach even a similar level of convergence. What gives? The data doesn't look like it would be inappropriate for this kind of prodecude, am I missing anything?


There are a few reasons why this was changed, the most important one was how upper and lower bound parameters ('u' and 'g') were handled internally and how their standard errors should be calculated. It made more sense to return the CI's rather than SE's in that case, so I changed all of the other parameters to follow suit.

There's an option now to print the original standard error format by passing coef(mod, printSE=TRUE), and that should work on the 1.2.1 version. If not, check out the dev version on Github, which certainly includes this feature.

Onto the other part of your model, with only two items it is not even uniquely identified, so I wouldn't expect the results to agree across versions or even operating systems; hence why the first a1 parameter has essentially an infinite standard error. You need at least 3 items per factor in order to identify the metric properly.

| cite | improve this answer | |
  • $\begingroup$ Thanks for the tips, I'll run this by my team. We were scratching our heads because mirt 0.5 was yielding the same results as (an admittedly old version of) Multilog. Maybe both were consistently converging to the same local minimums? $\endgroup$ – Waldir Leoncio Apr 14 '14 at 10:14
  • 1
    $\begingroup$ That's very possible the two programs would match, since they had similar implementation approaches at that time (TOL = .001, M-step optimizer set to Newton-Raphson, etc). More recent package versions use the BFGS optimizer in the M-step instead of the Newton-Raphson since it is much more stable (and uses the log-likelihood directly), and the TOL criteria is set lower (1e-4). Other things have changed as well internally, but those are the big ones which probably caused the difference. $\endgroup$ – philchalmers Apr 14 '14 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.