flatironinstitute / inferelator

Task-based gene regulatory network inference using single-cell or bulk gene expression data conditioned on a prior network.
BSD 2-Clause "Simplified" License
46 stars 12 forks source link

Arguments for BBSR model #51

Closed frankligy closed 1 year ago

frankligy commented 2 years ago

Hello,

I have a question regarding the BBSR model arguments (https://inferelator.readthedocs.io/en/latest/model_selection.html), from my understanding of the underlying principle, the value of g-prior controls the extent to which the inferred coefficient beta is either closer to 0 (prior) or to the OLS fit (data). A higher g-prior will result in a larger standard deviation of the coefficient which results in the beta more toward OLS fit.

If my understanding is correct, can I ask how these two arguments prior_weight and no_prior_weight correspond to the actual g-prior value in the BBSR model? Or in practice, how to parameterize the model if I want to (a) let the prior contribute nothing (b) let the prior contribute a lot to the model? It seems the default value for these two arguments are of value 1, doesn't that mean prior is not useful at all in the actual inference? I am thinking at least prior_weight=1, no_prior_weight=0, doesn't it?

Many thanks, Frank

asistradition commented 2 years ago

That's largely correct; the g-prior balances explaining more variance against being more sparse (the null model here is all zeros). For each gene, this is set on a per-regulator basis. Each regulator can be weighted to contribute more or less via setting these weights.

Setting both prior_weight and no_prior_weight to 1 means that each regulator will be regularized with the same weight, and that there is strong pressure for sparsity. You could change them both to 10, and each regulator will be regularized with the same weight, but there will be less pressure for sparsity - I think about it as sliding on the bias-variance scale.

These two weights are the same because we already heavily condition the modeling on the prior when we calculate TF activities. Because of that conditioning, I usually don't want to overweight priors in the modeling itself. Generally, I think the strength of this modeling strategy (conditioning the design matrix on the prior network) is that it lets you extend a sparse prior network by finding edges that aren't in the prior. I think it's somewhat less useful at taking a dense prior network and trying to eliminate noise edges (which is the most likely reason to downweight non-prior edges).

asistradition commented 2 years ago

As for how to let the prior network contribute nothing, that's pretty straightforward. Don't put one in (.set_network_data_flags(use_no_prior=True)). If you provide a prior network and calculate the transcription factor activity, your design matrix (and then the output of the modeling) will be conditioned on the prior network you put in, even if the actual modeling is agnostic to the presence or absence of edges in the prior network.

frankligy commented 2 years ago

Thanks so much for the explanation!