20 Feb
2008
20 Feb
'08
10:16 a.m.
Hello
I am in the process of coming up with an amelia() command for my survey
data, starting with a small subset to get a start and learn in the process.
It is about how to decide whether to specify variables as noms or ords.
When I look at my data (mostly ordered factors), I think I should use
the ords specification (see at bottom) and not "noms", but unfortunately
"ords" gives an error message whereas "noms" only gives warnings. --
Thus, my two questions are:
1) Which specification approach A or B is the correct (or better) one?
Or, more generally, should all factor variables be "noms=" and all
ordered factors be "ords="?
2) What do the warnings or the error message mean? What to do about them?
Thanks for having a look at it!
Marcus
t<-md[20:1000,1:12] # subset of full data frame
# First, to give you a feel for the data (output truncated)
t[1:8,1:10] # to get a feel for the data frame
id camp startyr exp.pjs insp.need insp.foss insp.pcss insp.feat
20 30019 free 1990 5 0 0 0 0
21 30020 <NA> NA 1 0 0 0 0
22 30021 free 2005 1 0 0 0 0
23 30022 both 2004 1 0 0 0 0
24 30023 both 2005 1 0 0 0 0
25 30024 both 2000 <NA> 0 0 0 1
26 30025 open 2004 5 0 0 0 1
27 30026 open 1985 30 0 1 0 0
str(t, give.attr=FALSE)
'data.frame':
981 obs. of 12 variables:
$ id : int 30019 30020 30021 30022 30023 30024 30025 30026 40001
$ camp : Factor w/ 3 levels "both","free",..: 2 NA 2 1 1 1 3 3 1
3
$ startyr : int 1990 NA 2005 2004 2005 2000 2004 1985 2002 1999 ...
$ exp.pjs : Ord.factor w/ 6 levels
"1"<"5"<"10"<"20"<..: 2 1 1 1 1 NA
$ insp.need: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 1 1 1 2 2
...
$ insp.foss: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 1 1 2 2 1
...
$ insp.pcss: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 1 1 1 1 1
...
$ insp.feat: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 2 2 1 2 2
...
$ insp.bugr: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 1 1 1 2 2
...
$ insp.insc: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 1 1 2 2 1
...
$ insp.outc: Ord.factor w/ 2 levels "0"<"1": 1 1 1 1 1 1 1 1 2 1
...
$ insp.offr: Ord.factor w/ 2 levels "0"<"1": 1 2 1 1 1 2 1 1 1 1
...
===== A) MI with variant "noms" =====
# specifying indep. variables as "noms"...
works...
t_noms<-amelia(t, p2s=2, m=5, idvars=c("id"),
noms=c("camp","exp.pjs","insp.need","insp.foss","insp.pcss","insp.feat","insp.bugr","insp.insc"))
... but gives warnings (usually 30-50, multiples of
ten it seems):
-- Imputation 5 --
setting up EM chain indicies
1(140) 2(0)
saving and cleaning
Es gab 50 oder mehr Warnungen (Anzeige der ersten 50 mit warnings())
warnings() # with English translation
50: Bedingung hat Länge > 1 und nur das erste Element wird benutzt in:
if (class(x.orig[, i]) == "logical") x.imp[, i] <- as.logical(x.imp[,
50: Condition has length>1 and only the first element is used in:
if (class...
# Plus: I occasionally get this warning (or error message?) in some
# Imputations:
The resulting variance matrix was not invertible. Please check your
data for highly collinear variables.
===== B) MI with variant "ords" =====
# specifying vars as ords throws an error message:
t_ords<-amelia(t, p2s=2, m=5,
idvars=c("id"), noms=c("camp"),
ords=c("exp.pjs","insp.need","insp.foss","insp.pcss","insp.feat","insp.bugr","insp.insc","insp.outc","insp.offr"))
amelia starting
Fehler in if (any(unique(na.omit(data[, i]))%%1 != 0)) { :
Fehlender Wert, wo TRUE/FALSE nötig ist
# Missing value, where TRUE/FALSE needed/expected
Zusätzlich: Warning message:
'%%' is not meaningful for ordered factors in:
Ops.ordered(unique(na.omit(data[, i])), 1)
--
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
20 Feb
20 Feb
8:51 p.m.
1) Which specification approach A or B is the correct
(or better) one?
Or, more generally, should all factor variables be "noms=" and all
ordered factors be "ords="?
My rule of thumb is that if you use an analytical technique that
treats the variable as normally distributed continuous, impute as
continuous. If you use an analytical approach that treats the data as
ordinal you can only impute as ordinal as a fraction will not be
interpretable for your analytical model.
As for the second problem, I have no idea. But I know Amelia (along
with all the other imputation methods I've seen) likes a very large
sample size. If you are using a subset that is too small, that might
be part of your problem. I'd give it a try with all the data just to
see if it runs.
HTH
L
-
Amelia mailing list served by Harvard-MIT Data Center
[Un]Subscribe/View Archive: http://lists.gking.harvard.edu/?info=amelia
25 Feb
25 Feb
6:14 a.m.
New subject: Hard to trace error message -- was: MI with categorical survey data: specifying vars as noms or ords?
Hello everybody
Thanks to Levi and Matt, I am clear now about the numeric/ords/noms
assigning and I am also using the whole dataset (N=2441).
But when I call Amelia, I still get that error message and a few warnings:
- The error message says "Missing value, where T/F was expected.", but
Amelia does not specify -where- this happens. I ran traceback() right
after but the output is not telling me much either (see below). How can
I locate more precisely where Amelia stumbles?
- Re the warnings: What is the problem if nominal variables have more
than 10 categories?
Thank you very much for your help,
Marcus
PS. I can provide more details on the Amelia call if needed.
# CALL
am <-
amelia(mdi,m=5,p2s=0,idvars=skip,noms=noms,ords=ords,collect=FALSE,
+
outname="Routput/imputed", write.out=TRUE,empri=NULL)
Fehler in if (any(unique(na.omit(data[, i]))%%1 != 0)) { :
Fehlender Wert, wo TRUE/FALSE nötig ist
Additional: Warning messages:
1:
The number of catagories in one of the variables marked nominal has
greater than 10 categories. Check nominal specification.
in: amcheck(data = data, m = m, idvars = numopts$idvars, priors = priors,
2:
... (dto. up to 5: )
6: '%%' is not meaningful for ordered factors in:
Ops.ordered(unique(na.omit(data[, i])), 1)
# TRACEBACK
traceback()
3: amcheck(data = data, m = m, idvars = numopts$idvars, priors = priors,
empri = empri, ts = numopts$ts, cs = numopts$cs, tolerance =
tolerance,
casepri = casepri, polytime = polytime, lags = numopts$lags,
leads = numopts$leads, logs = numopts$logs, sqrts = numopts$sqrts,
lgstc = numopts$lgstc, p2s = p2s, frontend = frontend, archive =
archive,
intercs = intercs, noms = numopts$noms, startvals = startvals,
ords = numopts$ords, collect = collect, outname = outname,
write.out = write.out)
2: amelia.prep(data = data, m = m, idvars = idvars, empri = empri,
ts = ts, cs = cs, tolerance = tolerance, casepri = casepri,
polytime = polytime, lags = lags, leads = leads, logs = logs,
sqrts = sqrts, lgstc = lgstc, p2s = p2s, frontend = frontend,
archive = archive, intercs = intercs, noms = noms, startvals =
startvals,
ords = ords, incheck = incheck, collect = collect, outname =
outname,
write.out = write.out, arglist = arglist, priors = priors,
autopri = autopri)
1: amelia(mdi, m = 5, p2s = 0, idvars = skip, noms = noms, ords = ords,
collect = FALSE, outname = "Routput/imputed", write.out = TRUE,
empri = NULL)
--
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
9:27 a.m.
New subject: Hard to trace error message -- was: MI with categorical survey data: specifying vars as noms or ords?
Hello
I got rid of all warnings unrelated to the Amelia error: Some of the
noms-specified variables had more than 10 levels (e.g., country codes),
so I moved them to idvars.
I think, however, that Amelia should behave differently in cases where a
fully observed nominal variable has more than 10 levels. Because now, I
had to remove complete and informative variables (like country codes)
from the imputation input and put them to the idvars list, which is not
considered for the imputation process.
This way, I am losing imputation information because Amelia forces the
removal of a fully observed nominal variable "only" because it has >10
levels. Shouldn't the fact of having fully observed variables take
precedence before the number of levels? -- Is there another possibility
to include these variables in the imputation input?
Finally, the error message (and a related warning) is still there:
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)
TIA,
Marcus
Am 25.02.2008 12:14 schrieb Marcus M. Dapp:
Hello everybody
Thanks to Levi and Matt, I am clear now about the numeric/ords/noms
assigning and I am also using the whole dataset (N=2441).
But when I call Amelia, I still get that error message and a few warnings:
- The error message says "Missing value, where T/F was expected.", but
Amelia does not specify -where- this happens. I ran traceback() right
after but the output is not telling me much either (see below). How can
I locate more precisely where Amelia stumbles?
- Re the warnings: What is the problem if nominal variables have more
than 10 categories?
Thank you very much for your help,
Marcus
PS. I can provide more details on the Amelia call if needed.
# CALL
--
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
am <-
amelia(mdi,m=5,p2s=0,idvars=skip,noms=noms,ords=ords,collect=FALSE,
+
outname="Routput/imputed", write.out=TRUE,empri=NULL)
Fehler in if (any(unique(na.omit(data[, i]))%%1 != 0)) { :
Fehlender Wert, wo TRUE/FALSE nötig ist
Additional: Warning messages:
1:
The number of catagories in one of the variables marked nominal has
greater than 10 categories. Check nominal specification.
in: amcheck(data = data, m = m, idvars = numopts$idvars, priors = priors,
2:
... (dto. up to 5: )
6: '%%' is not meaningful for ordered factors in:
Ops.ordered(unique(na.omit(data[, i])), 1)
# TRACEBACK
traceback()
3: amcheck(data = data, m = m, idvars = numopts$idvars, priors = priors,
empri = empri, ts = numopts$ts, cs = numopts$cs, tolerance =
tolerance,
casepri = casepri, polytime = polytime, lags = numopts$lags,
leads = numopts$leads, logs = numopts$logs, sqrts = numopts$sqrts,
lgstc = numopts$lgstc, p2s = p2s, frontend = frontend, archive =
archive,
intercs = intercs, noms = numopts$noms, startvals = startvals,
ords = numopts$ords, collect = collect, outname = outname,
write.out = write.out)
2: amelia.prep(data = data, m = m, idvars = idvars, empri = empri,
ts = ts, cs = cs, tolerance = tolerance, casepri = casepri,
polytime = polytime, lags = lags, leads = leads, logs = logs,
sqrts = sqrts, lgstc = lgstc, p2s = p2s, frontend = frontend,
archive = archive, intercs = intercs, noms = noms, startvals =
startvals,
ords = ords, incheck = incheck, collect = collect, outname =
outname,
write.out = write.out, arglist = arglist, priors = priors,
autopri = autopri)
1: amelia(mdi, m = 5, p2s = 0, idvars = skip, noms = noms, ords = ords,
collect = FALSE, outname = "Routput/imputed", write.out = TRUE,
empri = NULL)
12:48 p.m.
New subject: Hard to trace error message -- Error found, but it does not help...
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
1:43 p.m.
New subject: Hard to trace error message -- Error found, but it does not help...
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.
-
Amelia mailing list served by Harvard-MIT Data Center
[Un]Subscribe/View Archive: http://lists.gking.harvard.edu/?info=amelia
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
6:25 p.m.
New subject: Hard to trace error message -- Error found, but it does not help...
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:
-
Amelia mailing list served by Harvard-MIT Data Center
[Un]Subscribe/View Archive: http://lists.gking.harvard.edu/?info=amelia
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
26 Feb
26 Feb
5:44 a.m.
New subject: 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...
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
29 Feb
29 Feb
12:41 p.m.
New subject: Hard to trace error message -- alternatives?
Hello
If the problem I am having remains unsolved for the time being -- which
is not a reproach! I fully understand that Amelia developers also have
other things to do --, I would dare to ask the heretic question about
other R packages that would allow me to do MI?
Thank you very much,
Marcus
Am 26.02.2008 11:44 schrieb Marcus M. Dapp:
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...
--
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
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
5926
days inactive
5935
days old
amelia@lists.gking.harvard.edu
8 comments
3 participants
participants (3)
-
LevI Littvay (UNL) -
Marcus M. Dapp -
Matt Blackwell