Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • MI estimation problems in wide format

    I am seeing some unexpected behavior in estimation on multiply imputed (MI) data in wide format. When I load my MI dataset and run a simple estimation command (e.g. mi est: mean...), I get a value and the correct number of imputed observations. However, once I convert the dataset to wide format via mi convert wide, I get a different (presumably incorrect) value and a number of observations that appears to be the N BEFORE imputation. In other words, the imputed data appears to be totally disregarded. In fact after running mi convert wide, if I attempt to estimate a mean for a single imputation, I get the error "no observations." I do not get this error if I attempt to estimate the mean for the m=0 (non-imputed) data in wide format, or if I run the exact same command coverting to wide format. This is a major problem because my analysis requires merging replicate weights for correct calculation of standard errors, which can only be merged in wide format. (However, the issue I have just described is not related to this merge, because the error described occurs without merging weights)

  • #2
    Originally posted by Tod Van Gunten;n1403452[...
    This is a major problem because my analysis requires merging replicate weights for correct calculation of standard errors, which can only be merged in wide format.
    Are you sure? Where do you take this information from? Note that there is a special mi merge command, that should be used for merging with multiply imputed data. I have never used it but it would strike me as highly inconvenient if this would require a certain mi style to work correctly.

    As for the described problem, please show an example that we can replicate.

    Best
    Daniel

    Comment


    • #3
      that information comes from the team that designed the survey (this is a big publicly available dataset)...the survey documentation specifically recommends running the sequence

      mi convert wide
      merge 1:1 [id variables] using [replicate weights file]
      mi svyset...

      As noted however the problem I descibe occurs before running the merge... code.

      As to creating a replicable example, I'm not sure how to do so since I can't post the data here. However the code I am running is basically the following:

      use DATASET, clear
      mi est, esampvaryok: mean VARIABLE
      mi convert wide, clear
      mi est, esampvaryok: mean VARIABLE

      and as noted, I am getting a different result from the first to second estimation
      Last edited by Tod Van Gunten; 24 Jul 2017, 07:49.

      Comment


      • #4
        Hm, without at least seeing the output it will be hard to comment further. Anyway, the esamvaryok option looks scary. Why do you need this? Do make sure that you do fully understand what it does before specifying it. Note that if you have what Stata calls super-varying variables, these can only be stored in flong style, which might explain the problem that you are having. Read more about this in the pdf manual starting from

        Code:
        help mi set
        and run

        Code:
        mi varying
        Also note that, if a (fundamental) problem exists, just not converting your data does by no means necessarily solve this underlying problem.

        I would not follow the advice from the survey documentation. They might know their data but they do not seem to have (and probably cannot have) in-depth knowledge of Stata. If Stata dedicates a command for a specific purpose, I would recommend using this command, here mi merge. However, you obviously need to deal with the problem first.

        Edit:
        The clear option that you specify with mi convert should also not be specified, casually. Note that this is not recommended in the survey documentation. Whenever Stata forces you to specify clear it means that some information might be lost.


        Best
        Daniel
        Last edited by daniel klein; 24 Jul 2017, 08:08.

        Comment

        Working...
        X