I've review the code most of it looks good so far. I've run the examples and all of them run but I have a warning with the SVAE, GSM1 and GSM2 notebooks:

.../lib/python3.6/site-packages/bokeh/core/json_encoder.py:80: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.

This is related to the plotting in the very last cell of the notebooks. We probably want to fix it before to merge the code. (It's possible that the warning is already in the master branch... )

Regarding the code I have a couple of suggestions:

• The abstract class Model and ConjugateExponentialModel are now just empty shells. I think we can remove them right away.
• I don't know if we want to make it in this pull request but a version of the beer.training.mini_batches implemented in pytorch would be nice as we are moving to a fully pytorch version of the framework.
• Finally, I don't have strong opinion about it but I was thinking that beer.train_vae would be easier than beer.training.train_vae. Bokeh for instance is a library that has different packages and I always found it confusing as I never remember which function belongs to which package...

I will deal with the warning here (though it is present in the master as well :-P ). Then, I'll comment on the other issues you raised.

So, the issues is not ours to solve. See numpy/numpy#9505 for details. The Bokeh library just spell "np.float" instead of "np.floating".

The above commit partially adresses your first bullet -- the ConjugateExponetialModel is definitely not an empty shell.

I believe that exp_llh() should eventually go into the Model, because that is THE uniting property of all models considered -- to evaluate LLH of a datapoint. Therefore, I suggest we keep the Model anyway.

Ok, thanks to have checked for the warning. I have one more suggestion: you now have the function train_conj_exp. The name is quite cryptic and eventually misleading. I was thinking to rename it train_loglinear_model(...) which is not perfect but is a bit more explicit about the kind of model it treats. If you agree with the name I can take care of the renaming.

The third bullet and your renaming proposition have been adressed above.

As for the second bullet --- turning beer.training.mini_batches() into PyTorch implementation -- I think it should not happen now, but in bayesian_model_pytorch branch that will actually use it. Otherwise we probably break everything or end up merging that branch anyway

Sure, let's make this change when the pytorch version of the log-linear models is finished. I think it's almost finished. As a final change I would eventually add a docstring to train_vae and train_loglinear_model as these functions will be used extensively with different settings. I can write it if you want.

Otherwise, if you agree, we can merge it now to the master.