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...
am <-
amelia(mdi,m=5,p2s=2,idvars=ids,noms=noms,ords=ords,collect=FALSE,
+
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
traceback()
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
> <blackwel(a)fas.harvard.edu> 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 <mdapp(a)ethz.ch> 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.
>> >
>> >
am <-
amelia(mdi,m=5,p2s=2,idvars=ids,noms=noms,ords=ords,collect=FALSE,
>> > +
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