Imputation functionality

[ericbair-sciome]

Functions to impute data (due to limit of detection or otherwise) need to be added to the package.

[kyle-messier]

@brian-bk22 @ericbair-sciome The overall functionality was added with PR #56 . For the pesticide work, we need to allow for variable LOD. Currently it appears that each outcome can only have 1 LOD:
Error in check_input(model, Y, X, locs, center.y, impute.y, lod) : Each lod must have length 1

Also, we don't have to implement this now if it is not trivial, but I think a more standard or straight forward approach
to implement an LOD would be to have a single value for the Y and then an indicator for whether it is observed or a limit of detection.

[ericbair-sciome]

I had been meaning to ask you about that. I thought you had said something about that in one of our meetings, but I wasn't sure. I'll go ahead and change this. It should be an easy fix.

By the way, I have finished my more detailed testing of the imputation algorithm. It seems to work very well for MAR missingness, but there is some bias in the LOD case. (And it gets steadily worse as the proportion of missing data increases.) I'm hoping to send a new version to Shail tonight. (Everything is done other than documentation at this point plus the aforementioned change, which should be easy.) My plan was to fix the show/accessor methods after that (since that is important for model interpretation) and then double back to see if we can figure out a way to improve the LOD imputation.

[kyle-messier]

@ericbair-sciome Thanks for the quick reply and fix. That is good to hear it will be an easy fix. For the LOD imputation effectiveness, also good to hear it is working for random case. It is expected that it will get worst as the proportion of missingness increases. One thing I mentioned in an email was the idea of multiple imputation. I'm developing the pesticide analysis through the targets package, which makes mapping over parameters easy and reproducible. We'll see how the analysis turns out, but we could discuss the idea of fitting k different PrestoGP models where each imputation is allowed to vary and average over those.

As an example, here is the current working version of the visualization of the targets pipeline. I have pre-processing, exploratory analysis, testing on a vanilla glmnet model, sub-sample dataset for testing PrestoGP, which is where it is currently failing:

[kyle-messier]

@ericbair-sciome Also, question related to the scaling input in prestogp_fit. Does it need to be a list for each outcome? Or would something like c(1,1,2) be sufficient for the multivariate. I think the latter is fine. I can't imagine a scenario where you would allow each outcome to vary in terms of a spatial vs spatiotemporal model.

[ericbair-sciome]

No, there is one scaling input for all outcomes for basically the reason you just said. :)

[ericbair-sciome]

@brian-bk22 @ericbair-sciome The overall functionality was added with PR #56 . For the pesticide work, we need to allow for variable LOD. Currently it appears that each outcome can only have 1 LOD: Error in check_input(model, Y, X, locs, center.y, impute.y, lod) : Each lod must have length 1

Also, we don't have to implement this now if it is not trivial, but I think a more standard or straight forward approach to implement an LOD would be to have a single value for the Y and then an indicator for whether it is observed or a limit of detection.

As an FYI, in the latest version, each outcome can have a separate LOD. Let me know if the syntax is unclear and I will try to improve the documentation.

I'm going to keep this issue open for now. While imputation is implemented in the current release, it seems to be biased when the percentage of missing data due to LOD is very high. We are working on some alternative approaches that seem to work better. If all goes well, we should have an improved imputation algorithm implemented in the next few weeks.

[ericbair-sciome]

This took much longer than I hoped, but the imputation functionality is significantly improved in the new version. There are still issues that need to be worked out. In particular, I think the new version is going to be prohibitively slow when the number of missing values is high. But I think I will close this issue and create some new issues for the new unresolved problems.

[kyle-messier]

@ericbair-sciome Thanks and no worries. I'm also taking longer on getting the pesticide data processed for analysis. I'll check out the new version ASAP. One question in regards to computational time. Does the new imputation method allow the user to control the number of iterations or the tolerance in re-estimating $\beta$ ?

[ericbair-sciome]

At the moment, the number of iterations and tolerance are hard coded. I should probably give users the option of changing that. I'll put that on the list to do.

[kyle-messier]

@ericbair-sciome Great - thank you. Whatever it is set to right now can be an easy default, but control would be good if someone wants to sacrifice some precision for speed. A print() or verbose option would be good to output each iterations value to monitor how long things are taking to converge.

[ericbair-sciome]

Good suggestions. I'll put that on the list.