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

extend sleuth to model TPMs #145

Merged
merged 9 commits into from
Mar 12, 2018
Merged

extend sleuth to model TPMs #145

merged 9 commits into from
Mar 12, 2018

Conversation

warrenmcg
Copy link
Collaborator

@warrenmcg warrenmcg commented Nov 3, 2017

Hi @pimentel,

This is the code to extend sleuth in prep for sleuth-ALR.

Here is a summary of the changes:

Transform both counts and TPMs independently

  • split the transformation function into one for counts, and a separate one for TPMs. Default for counts is still log(x + 0.5); default for TPMs is identity (i.e. x --> x, or not transformed).

Process TPMs & counts similarly with process_bootstraps and sleuth_prep

  • added code to process_bootstraps and sleuth_prep to process TPMs similar to how counts are processed (transform TPM values; create obs_tpm and sigma_q_sq_tpm)
  • importantly, gene mode only processes counts when extra_bootstrap_summary is TRUE and only processes TPMs when read_bootstrap_tpm is TRUE (may speed up processing if someone is just interested in one or the other)

allow TPMs to modeled by sleuth_fit

  • added which_var option to sleuth_fit to specify obs_counts (default) or obs_tpm; added to the print function for sleuth_fit objects to print which variable was modeled (counts or TPMs).

remaining to-dos:

  • extend sleuth_live to allow users to look at TPM or counts if both are modeled. DONE
  • right now, if users want to model both TPMs and counts on the same model, they have to be stored separately; I think this should remain the case, but wanted to check on this design decision. We decided users will be forced to model each separately.

…ocessing bootstraps, and set up TPM values for use in sleuth fit
…y modify 'bs_quants' if 'extra_sbootstrap_summary' is TRUE
…e default estimated counts:

+ Add 'which_var' option to 'sleuth_fit', which accepts 'obs_counts' or 'obs_tpm'
+ Add sanity check to make sure 'which_var' exists in the 'bs_summary' list.
+ Add 'which_var' as an additional item in the fit, so users can check which data was modeled.
@warrenmcg
Copy link
Collaborator Author

Hey @pimentel, so I think I've covered my bases with the two to-dos. I don't see other clear opportunities for users to need to know whether counts or TPMs are modeled within the sleuth_live environment. I think the print function for sleuth_model objects is sufficient for users to double-check which variable was modeled. Let me know what you think.

@pimentel pimentel merged commit 03a18fd into pachterlab:devel Mar 12, 2018
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

Successfully merging this pull request may close these issues.

2 participants