[amelia] Re: Hard to trace error message -- imputation is now starting, but not finishing.

Matt, Thank you for the quick response and patch! I really appreciate it. :-) I just updated Amelia and ran it again. It start with the first imputation, so the ords/noms problem is fixed. Great! Unfortunately, it then hits an "index out of bounds" error. See below... + outname="Routput/imputed", write.out=TRUE,empri=NULL) amelia starting beginning prep functions running bootstrap -- Imputation 1 -- setting up EM chain indicies 1(3153) 2(2266) 3(1683) 4(872) 5(334) 6(170) 7(129) 8(108) 9(97)10(73) 11(59)12(47)13(39)14(30)15(18)16(13)17(6)18(5)19(2)20(1) 21(0) Fehler in unsubset(x.orig = prepped$trans.x, x.imp = ximp, blanks = prepped$blanks, : Indizierung außerhalb der Grenzen 2: unsubset(x.orig = prepped$trans.x, x.imp = ximp, blanks = prepped$blanks, idvars = prepped$idvars, ts = prepped$ts, cs = prepped$cs, polytime = polytime, intercs = intercs, noms = prepped$noms, index = prepped$index, ords = prepped$ords) 1: amelia(mdi, m = 5, p2s = 2, idvars = ids, noms = noms, ords = ords, collect = FALSE, outname = "Routput/imputed", write.out = TRUE, empri = NULL) I guess the code snippet is in "amelia" (row 81), but I am not sure. Anyway, I do not understand it. -- If I can be of use in providing additional (trace) information, please let me know. Feel free to send trace commands I should run as I am not very familiar with R. Thank you very much. Marcus Am 26.02.2008 00:25 schrieb Matt Blackwell: > Hello all, > > We have worked out the bug involving factors and ordinal variables. > You can run get the most up-to-date code by running the following line > of code at the R command line: > > install.packages("Amelia",repos="http://gking.harvard.edu") > > You should now be able to use all of the factors your heart desires as > ordinal variables in Amelia. > > Thanks, > matt. > > On Mon, Feb 25, 2008 at 1:43 PM, Matt Blackwell > &lt;blackwel(a)fas.harvard.edu&gt; wrote: >> Hi Marcus, >> >> The problem is simply a bug in Amelia's front-end error checking. The >> specific check in question is trying to make sure that any variable >> you have set as ordinal is, in fact, integer-valued. The check >> involves some matrix algebra that does not work on factors. I'm in the >> process of fixing the bug now, but in the meantime, there is a >> workaround. >> >> mdi.am <- mdi >> mdi.am[,1] <- as.numeric(mdi.am[,1]) >> >> m <- 5 >> amelia.out <- amelia(mdi.am, m=m, ords=1) >> >> for (i in 1:m) { >> amelia.out[[i]][,1] <- factor(amelia.out[[i]][,1], levels=levels(mdi[,1])) >> } >> >> this code is untested, but it should work, unless you have an NA >> before one of the levels of your factor. It's a hack, but it should >> work for now. The bug fix should be sometime soon and I'll email the >> list when it is. >> >> Thanks for your help in finding this. >> matt. >> >> >> >> On Mon, Feb 25, 2008 at 12:48 PM, Marcus M. Dapp &lt;mdapp(a)ethz.ch&gt; wrote: >> > Hello >> > >> > I am sorry for flooding the list, but that problem really keeps me from >> > starting the data analysis. Good news: I found out where the error >> > occurs and what causes it. The bad news: It does not help. >> > >> > >> > + outname="Routput/imputed", write.out=TRUE,empri=NULL) >> > >> > amelia starting >> > Fehler in if (any(unique(na.omit(data[, i]))%%1 != 0)) { : >> > Fehlender Wert, wo TRUE/FALSE nötig ist >> > Zusätzlich: Warning message: >> > '%%' is not meaningful for ordered factors in: >> > Ops.ordered(unique(na.omit(data[, i])), 1) >> > >> > >> > The "any(uniqeu(...)" code snippet is located within the "amcheck" >> > function, around row #462, and it looks like this: >> > >> > if (!is.null(ords)) { >> > for (i in ords) { >> > if (any(unique(na.omit(data[, i]))%%1 != 0)) { >> > error.code <- 44 >> > error.mess <- paste("You have designated a variable as >> > ordinal when it has non-integer values.") >> > return(list(code = error.code, mess = error.mess)) >> > } >> > } >> > } >> > >> > My interpretation: The modulo operator %% is used to check whether the >> > ords variable contains in fact integer values. So, I tested the relevant >> > line of code manually with the first ords variable that is passed to >> > amelia(). It leads to an "NA" and above error message that %% is not >> > meaningful for ordered factors: >> > >> > > any(unique(na.omit(mdi[,1]))%%1 != 0) >> > >> > [1] NA >> > Warning message: >> > %% nicht sinnvoll für Faktoren in: Ops.factor(unique(na.omit(mdi[, 1])), 1) >> > >> > BUT the concerned variable looks OK to me: >> > >> > > check(mdi[,1]) >> > Factor w/ 3 levels "both","free",..: 2 2 3 3 2 1 3 3 1 3 ... >> > both free open NA's >> > 1032 504 886 19 >> > >> > All values are integers or NA. (I also did this check for some of the >> > remaining ords variables. The same result.) >> > >> > Does somebody have an idea what the problem could be? I am grateful for >> > any hints because else I would have to look for another solution to MI... >> > >> > Thank you very much! >> > >> > Kind regards, >> > Marcus >> > >> > -- >> > >> > Marcus M. Dapp | PhD student | ETH Zurich | www.ib.ethz.ch/people/mdapp >> > Prof. Thomas Bernauer, International Relations | www.ib.ethz.ch >> > >> > On the shoulders of giants? http://science.creativecommons.org >> > - >> > Amelia mailing list served by Harvard-MIT Data Center >> > [Un]Subscribe/View Archive: http://lists.gking.harvard.edu/?info=amelia >> > >> > >> > - > Amelia mailing list served by Harvard-MIT Data Center > [Un]Subscribe/View Archive: http://lists.gking.harvard.edu/?info=amelia -- Marcus M. Dapp | PhD student | ETH Zurich | www.ib.ethz.ch/people/mdapp Prof. Thomas Bernauer, International Relations | www.ib.ethz.ch On the shoulders of giants? http://science.creativecommons.org - Amelia mailing list served by Harvard-MIT Data Center [Un]Subscribe/View Archive: http://lists.gking.harvard.edu/?info=amelia