Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interface with mashr #22

Open
stephens999 opened this issue Apr 19, 2024 · 12 comments
Open

interface with mashr #22

stephens999 opened this issue Apr 19, 2024 · 12 comments

Comments

@stephens999
Copy link
Collaborator

we should document how to use this with mashr, probably in the mashr vignette?
It may require writing a function or functions to produce mashr objects (priors?) in the udr package?

@pcarbo
Copy link
Member

pcarbo commented Apr 19, 2024

Yes, that's a good idea, but perhaps it makes sense to tackle Issue #21 first, and then illustrate the (more user-friendly) interface in the vignette.

@stephens999
Copy link
Collaborator Author

related to stephenslab/mashr#132

  • does udr handle missing data?
  • Can we fit both the EE and EZ model with udr?

@yunqiyang0215
Copy link
Collaborator

@stephens999 udr handles missing data using mashr function. The input to ud_init() can be a mashr object, and handling missingness part is using mashr.

We can fit both EE and EZ model with udr.

@stephens999
Copy link
Collaborator Author

stephens999 commented Nov 5, 2024 via email

@yunqiyang0215
Copy link
Collaborator

I think V is for covariance for udr.

@stephens999
Copy link
Collaborator Author

i think we should think a bit about this.
If we keep that different convention in the two packages
then we should probably not mix the mash data object with the udr V as inputs to the same function.

For example, currently we allow both a mash_data object and V to be provided to udr_init, but
then it's confusing: not clear if the V refers to the udr V or the mashr V.
Maybe it would be enough to not allow the user to specify both?

Or maybe it would be better to be consistent about the use of V in the two packages?

@yunqiyang0215
Copy link
Collaborator

Agree... Would be better to be consistent about the notation V. The only concern is if we change udr software, the notation will be different from what we wrote in paper.

@stephens999
Copy link
Collaborator Author

it turns out the same is true for mashr: we use V for variance in the paper, but for correlation in the software

@stephens999
Copy link
Collaborator Author

@pcarbo do you have thoughts on how to proceed?

@pcarbo
Copy link
Member

pcarbo commented Nov 7, 2024

We should do our best to make sure the udr interface is consistent with the existing mashr interface. (This doesn't necessarily mean we need to change the variable names in the underlying implementation. But the input arguments in the exported functions should be consistent.)

@stephens999
Copy link
Collaborator Author

the mashr interface is built around the notion of a "data" object, which contains Bhat, Shat (optional; default is 1) and a correlation matrix (or list of correlation matrices) V.
Do we want to build udr around the same type of object?

@pcarbo
Copy link
Member

pcarbo commented Nov 7, 2024

Definitely!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants