pyro-ppl / brmp

Bayesian Regression Models in Pyro
Apache License 2.0
69 stars 8 forks source link

Interface changes #68

Closed null-a closed 4 years ago

null-a commented 4 years ago

The aim of this PR is to (a) simplify the public interface for defining models and running inference (partially addressing #32), and (b) to introduce a new interface (for the same purpose) that is less convenient but more flexible.

The main change to the public interface is that there is no longer an explicit generate step when defining a model. A further minor change is that defm is renamed to brm. For example:

# before
fit = defm('y ~ x', df).generate(numpyro).fit(algo='nuts', iter=10)
# after
fit = brm('y ~ x', df).fit(algo='nuts', iter=10, backend=numpyro)
# alternatively
fit = brm('y ~ x', df).nuts(iter=10, backend=numpyro)

While it was already possible to avoid explicitly calling generate, its presence in the docs makes things seem a bit more complicated than they need to be. I think this change helps make things quite a bit clearer. Comparing the docs before and after this PR shows this I think.

The downside to this change is that we lose some (less frequently used) functionality. e.g. It's no longer possible to inspect the generated model code without first fitting the model. However, the new (currently private/undocumented) interface facilitates this and more. Typical usage:

model = define_model('y ~ x', metadata).gen(numpyro)
data = model.encode(df)
fit = model.run_algo('nuts', data, iter=10)

The addition of this extra interface was motivated by the OED branch, where it's useful to have a convenient way to (a) define a model before collecting data (define_model) , and (b) to run inference multiple times on different data. (I imagine this could also be used to simplify some tests -- I'll look at a making a follow-up PR for that.)

There's likely room to improve this over time, but heading in this general direction seems OK to me. What do you think?

neerajprad commented 4 years ago

(b) to introduce a new interface (for the same purpose) that is less convenient but more flexible.

Did you mean the other way round? :) This seems more convenient.

null-a commented 4 years ago

Great, thanks @neerajprad.