0.3 release checklist

[fehiepsi]

Here we list issues that we want to address for the next release:

• Port pyro.infer.reparam Add reparam handler #599
• Remove all base_param_map/transform_with_intermediates stuffs to simplify our codebase. Remove AutoContinuousELBO. Remove base_param_map #601
• Update neutra, neal_funnel, eight_schools examples to reflect the usage of reparam
• Update the pattern to define improper prior Switch to use mask(False) for improper prior #605
• Move autoguide to the infer module.
• Refactor initialization strategies, following Pyro versions. Revise the pattern of subsitute_fn because it is used incorrectly, as mention at this comment Refactor initialization strategies #606
• Unifies the pattern of returning statistics for deterministic sites
• Optimize compiling time for MCMC #585 Addresses compiling issues
• Add some control_flow primitives Add scan primitive #595
• [ ] improve gradient computation of eucledian kinetic energy #567 Enhance kinetic_energy API, based on recent refactoring in Pyro. This should allow users to set initial mass matrix expose inverse mass matrix #536 edit It is not clear which API we should change... so I would like to defer this to future PRs when structure mass matrix is required.
• Initial support for models with discrete latent variable. We can defer advanced stuff such as markov for later releases.
• Update readme eight school example using reparam.
• Update notebooks
• Update jax/jaxlib to the latest version:
  • Use the convention import jax.numpy as jnp Use the convention jax.numpy -> jnp #590
  • Use the upstream logsumexp again
  • Use lax.switch for multiple branches
  • Use the upstream poisson sampler
• some tweaks
  • remove device put in poisson
  • match Pyro api for condition, substitute, scale, Pareto, MultivariateAffineTransform...
  • verify all the docs are generated as expected
  • PRNGKey log_prob issue
  • remove contrib/distributions

[fehiepsi]

@neerajprad I want to remove the support for improper prior through pyro.param. The reasons are:

• We can achieve the same purpose by using sample(name, dist.Foo().mask(False)). Using sample is better because we can draw samples from the (improper) prior to get initial values; rather than a fixed value from param statement.
• The distinguish between param and sample is clearer.
• Keeps the behavior like in Pyro, without losing functionality.

There are some other technical benefits:

• I want to resolve the issue to get initial values here. There we used the same subkey for all sites. I think an easy fix is to use substitute(seed(model, ...), substitute_fn=..., so each sample site will have rng_key before applying substitute_fn. Then we can use that rng_key inside init strategies. But this won't work for param statement.
• With that, we can remove skip_params flag. This allows users specify init_strategy using init_to_uniform in addition to init_to_uniform(radius=3) (Pyro behavior). I think that the current pattern has made @martinjankowiak confused.

What do you think?

[neerajprad]

Removing support seems fine to me and +1 to more uniformity with Pyro's syntax. We should just make sure that we document and raise a warning/error that tells users how to change their code. I'm curious to see your .mask(False) solution. Let's discuss that when you have a PR up.

[fehiepsi]

@neerajprad I think that my last refactoring job is to split SA implementation from mcmc.py file, as you requested in the last release. Another point that you wanted to discuss was whether or not to include deterministic sites to the output of AutoGuide.get_posterior. What is your opinion about it now? (the current behavior is to include deterministic sites to the output) I think that's all pending tasks that I can remember. If you want to discuss or address something else for 0.3 release, please feel free to edit the topic tasks.

[neerajprad]

@neerajprad I think that my last refactoring job is to split SA implementation from mcmc.py file, as you requested in the last release.

This is purely an internal code organization related change, so it shouldn't block us from releasing.

Another point that you wanted to discuss was whether or not to include deterministic sites to the output of AutoGuide.get_posterior. What is your opinion about it now? (the current behavior is to include deterministic sites to the output)

I don't recall the discussion right now, and the arguments for each. Could you point me to it? In any case, I don't think any of these issues should be blocking us from doing a release.

The only thing that will be nice to have is usage of scan in some tutorial / example. Can we modify our time series forecasting example to use your modified scan. We can do this after the release btw and update the tutorial.

[fehiepsi]

The discussion that we deferred for later about autoguide is from #601 (comment)

I think I can modify ts forecasting example to illustrate scan. Nice suggestion!! Thanks ;)

[fehiepsi]

I created this issue to track down issues for 0.3 release. Most of them are addressed or in reviewing so I will close this now.