make.jl modifs

Author: js-d

docs/.jekyll-cache/Jekyll/Cache/Jekyll--Cache/b7/9606fb3afea5bd1609ed40b622142f1c98125abcfe89a76a661b0e8e343910

@@ -0,0 +1 @@
+I"�{"source"=>"/Users/js/Turing.jl/docs", "destination"=>"/Users/js/Turing.jl/docs/_site", "collections_dir"=>"", "cache_dir"=>".jekyll-cache", "plugins_dir"=>"_plugins", "layouts_dir"=>"_layouts", "data_dir"=>"_data", "includes_dir"=>"_includes", "collections"=>{"posts"=>{"output"=>true, "permalink"=>"/:collection/:path"}, "docs"=>{"output"=>true, "permalink"=>"/:collection/:path"}, "tutorials"=>{"output"=>true, "permalink"=>"/:collection/:path"}, "team"=>{"output"=>true, "permalink"=>"/:collection/:path"}}, "safe"=>false, "include"=>[".htaccess"], "exclude"=>[".gems", "_site", "CHANGELOG.md", "CNAME", "LICENSE", "src", "Gemfile", "Gemfile.lock", "jekyll-build", "make.jl", "make-utils.jl", "README.md", "vendor", "test.sh", "*.org", ".sass-cache", ".jekyll-cache", "gemfiles", "node_modules", "vendor/bundle/", "vendor/cache/", "vendor/gems/", "vendor/ruby/"], "keep_files"=>[".git", ".svn"], "encoding"=>"utf-8", "markdown_ext"=>"markdown,mkdown,mkdn,mkd,md", "strict_front_matter"=>false, "show_drafts"=>nil, "limit_posts"=>0, "future"=>false, "unpublished"=>false, "whitelist"=>[], "plugins"=>["jekyll-paginate", "jekyll-sitemap", "jekyll-gist", "jekyll-feed", "jemoji", "jekyll-sitemap"], "markdown"=>"kramdown", "highlighter"=>"rouge", "lsi"=>false, "excerpt_separator"=>"\n\n", "incremental"=>false, "detach"=>false, "port"=>"4000", "host"=>"127.0.0.1", "baseurl"=>"/dev", "show_dir_listing"=>false, "permalink"=>"/:year/:title/", "paginate_path"=>"/page:num", "timezone"=>nil, "quiet"=>false, "verbose"=>false, "defaults"=>[{"scope"=>{"path"=>"_docs", "type"=>"docs"}, "values"=>{"layout"=>"page", "sidebar"=>true}}, {"scope"=>{"path"=>"_tutorials", "type"=>"tutorials"}, "values"=>{"layout"=>"page", "sidebar"=>true}}, {"scope"=>{"path"=>"", "type"=>"pages"}, "values"=>{"layout"=>"page", "sidebar"=>true}}, {"scope"=>{"path"=>"_team", "type"=>"team"}, "values"=>{"layout"=>"team", "sidebar"=>false}}, {"scope"=>{"path"=>"_posts", "type"=>"posts"}, "values"=>{"layout"=>"post", "sidebar"=>false}}], "liquid"=>{"error_mode"=>"warn", "strict_filters"=>false, "strict_variables"=>false}, "kramdown"=>{"auto_ids"=>true, "toc_levels"=>[1, 2, 3, 4, 5, 6], "entity_output"=>"as_char", "smart_quotes"=>"lsquo,rsquo,ldquo,rdquo", "input"=>"GFM", "hard_wrap"=>false, "guess_lang"=>true, "footnote_nr"=>1, "show_warnings"=>false}, "title"=>"Turing.jl", "email"=>"[email protected]", "author"=>"The Turing Team", "description"=>"Turing: A robust, efficient and modular library for general-purpose probabilistic programming.\n", "url"=>"http://localhost:4000", "repo"=>"https://github.com/TuringLang/Turing.jl", "github_user"=>"TuringLang", "github_repo"=>"Turing.jl", "twitter"=>"Turingjl", "linkedin"=>"Turingjl", "dockerhub"=>"Turingjl", "logo"=>"assets/img/favicon.ico", "logo_pixels"=>34, "color"=>"#d2e6f5", "navbarcolor"=>"#073c44", "tag_search_endpoint"=>"https://ask.cyberinfrastructure.org/search?q=", "tag_color"=>"danger", "accentColor"=>"red", "themeColor"=>"red", "fixedNav"=>"true", "livereload_port"=>35729, "serving"=>true, "watch"=>true}:ET

docs/.jekyll-cache/Jekyll/Cache/Jekyll--Converters--Markdown/07/51a06dca8ab3c5ee1c930f352a46e04b4917d60539374d0c48341afbe2378a

@@ -0,0 +1,2 @@
+I"{<h1 id="unsupervised-learning-using-bayesian-mixture-models">Unsupervised Learning using Bayesian Mixture Models</h1>
+:ET

docs/.jekyll-cache/Jekyll/Cache/Jekyll--Converters--Markdown/0c/bdd2c7e09c73969e49a50db33b5efcb8447d8e1a18ca2e450e443c48797f0a

@@ -0,0 +1,2 @@
+I"�
<p>In this section, I will describe the current design of Turing’s model compiler which enables Turing to perform various types of Bayesian inference without changing the model definition. What we call “compiler” is essentially just a macro that transforms the user’s code to something that Julia’s dispatch can operate on and that Julia’s compiler can successfully do type inference on for efficient machine code generation.</p>
+:ET

docs/.jekyll-cache/Jekyll/Cache/Jekyll--Converters--Markdown/0d/f71da6b060a87608f28093bcdc922ff506c34fbf85722c9162f37168f75c5b

@@ -0,0 +1,58 @@
+I"�<p>The Turing.jl team is currently exploring possibilities in an attempt to help with the ongoing SARS-CoV-2 crisis. As preparation for this and to get our feet wet, we decided to perform a replication study of the <a href="https://www.imperial.ac.uk/mrc-global-infectious-disease-analysis/covid-19/report-13-europe-npi-impact/">Imperial Report 13</a>, which attempts to estimate the real number of infections and impact of non-pharmaceutical interventions on COVID-19. In the report, the inference was performed using the probabilistic programming language (PPL) Stan. We have explicated their model and inference in Turing.jl, a Julia-based PPL. We believe the results and analysis of our study are relevant for the public, and for other researchers who are actively working on epidemiological models. To that end, our implementation and results are available <a href="https://github.com/cambridge-mlg/Covid19">here</a>.</p>
+
+<p>In summary, we replicated the Imperial COVID-19 model using Turing.jl. Subsequently, we compared the inference results between Turing and Stan, and our comparison indicates that results are reproducible with two different implementations. In particular, we performed 4 sets of simulations using the Imperial COVID-19 model. The resulting estimates of the expected real number of cases, in contrast to the <em>recorded</em> number of cases, the reproduction number \(R_t\), and the expected number of deaths as a function of time and non-pharmaceutical interventions (NPIs) for each Simulation are shown below.</p>
+
+<div id="simulation-1-full" class="plotly"></div>
+<script>
+ Plotly.d3.json("../assets/figures/2020-05-04-Imperial-Report13-analysis/full_prior.json", function(err, fig) {
+   Plotly.plot("simulation-1-full", fig.data, fig.layout, {responsive: true});
+ });
+</script>
+
+<p><strong>Simulation (a):</strong> hypothetical Simulation from the model without data (prior predictive) or non-pharmaceutical interventions. Under the prior assumptions of the Imperial Covid-19 model, there is a very wide range of epidemic progressions with expected cases from almost 0 to 100% of the population over time. The black bar corresponds to the date of the last observation. Note that \(R_t\) has a different time-range than the other plots; following the original report, this shows the 100 days following the country-specific <code class="language-plaintext highlighter-rouge">epidemic_start</code> which is defined to be 31 days prior to the first date of 10 cumulative deaths, while the other plots show the last 60 days.</p>
+
+<div id="simulation-2-full" class="plotly"></div>
+<script>
+ Plotly.d3.json("../assets/figures/2020-05-04-Imperial-Report13-analysis/full_posterior.json", function(err, fig) {
+   Plotly.plot("simulation-2-full", fig.data, fig.layout, {responsive: true});
+ });
+</script>
+
+<p><strong>Simulation (b):</strong> future Simulation with non-pharmaceutical interventions kept in place (posterior predictive). After incorporating the observed infection data, we can see a substantially more refined range of epidemic progression. The reproduction rate estimate lies in the range of 3.5-5.6 before any intervention is introduced. The dotted lines correspond to observations, and the black bar corresponds to the date of the last observation.</p>
+
+<div id="simulation-3-full" class="plotly"></div>
+<script>
+ Plotly.d3.json("../assets/figures/2020-05-04-Imperial-Report13-analysis/full_counterfactual.json", function(err, fig) {
+   Plotly.plot("simulation-3-full", fig.data, fig.layout, {responsive: true});
+ });
+</script>
+
+<p><strong>Simulation (c):</strong> future Simulation with non-pharmaceutical interventions removed. Now we see the hypothetical scenarios after incorporating infection data, but with non-pharmaceutical interventions removed. This plot looks similar to Simulation (a), but with a more rapid progression of the pandemic since the estimated reproduction rate is bigger than the prior assumptions. The dotted lines correspond to observations, and the black bar corresponds to the date of the last observation.</p>
+
+<div id="simulation-4-full" class="plotly"></div>
+<script>
+ Plotly.d3.json("../assets/figures/2020-05-04-Imperial-Report13-analysis/full_counterfactual2.json", function(err, fig) {
+   Plotly.plot("simulation-4-full", fig.data, fig.layout, {responsive: true});
+ });
+</script>
+
+<p><strong>Simulation (d):</strong> future Simulation with when <code class="language-plaintext highlighter-rouge">lockdown</code> is lifted two weeks before the last observation (predictive posterior). As a result there is a clear, rapid rebound of the reproduction rate. Comparing with Simulation (b) we do not observe an <em>immediate</em> increase in the number of expected cases and deaths upon lifting lockdown, but there is a significant difference in the number of cases and deaths in the last few days in the plot: Simulation (d) results in both greater number of cases and deaths, as expected. This demonstrates how the effects of lifting an intervention might not become apparent in the measurable variables, e.g. deaths, until several weeks later. The dotted lines correspond to observations, the black bar corresponds to the date of the last observation, and the red bar indicates when <code class="language-plaintext highlighter-rouge">lockdown</code> was lifted.</p>
+
+<p>Overall, Simulation (a) shows the prior modelling assumptions, and how these prior assumptions determine the predicted number of cases, etc. before seeing any data. Simulation (b) predicts the trend of the number of cases, etc. using estimated parameters and by keeping all the non-pharmaceutical interventions in place. Simulation (c) shows the estimate in the case where none of the intervention measures are ever put in place. Simulation (d) shows the estimates in the case when the lockdown was lifted two weeks prior to the last observation while keeping all the other non-pharmaceutical interventions in place.</p>
+
+<p>We want to emphasise that we do not provide additional analysis of the Imperial model yet, nor are we aiming to make any claims about the validity or the implications of the model. Instead we refer to Imperial Report 13 for more details and analysis. The purpose of this post is solely to add validation to the <em>inference</em> performed in the paper by obtaining the same results using a different probabilistic programming language (PPL) and by exploring whether or not Turing.jl can be useful for researchers working on these problems.</p>
+
+<p>For our next steps, we’re looking at collaboration with other researchers and further developments of this and similar models.
+There are some immediate directions to explore:</p>
+<ol>
+  <li>Incoporation of more sources of data, e.g. national mobility, seasonal changes and behavior changes in individuals.</li>
+  <li>How the assumptions incorporated into the priors and their parameters change resulting posterior.</li>
+  <li>The current model does not directly include recovery as a possibility and assumes that if a person has been infected once then he/she will be infectious until death. Number of recovered cases suffers from the same issues as the number of cases: it cannot be directly observed. But we can also deal with it in a similar manner as is done with number of cases and incorporate this into the model for a potential improvement.
+This will result in a plethora of different models from which we can select the most realistic one using different model comparions techniques, e.g. leave-one-out cross-validation (loo-cv).</li>
+</ol>
+
+<p>Such model refinement can be potentially valuable given the high impact of this pandemic and the uncertainty and debates in the potential outcomes.</p>
+
+<p><strong>Acknowledgement</strong> <em>We would like to thank the Julia community for creating such an excellent platform for scientific computing, and for the continuous feedback that we have received. We also thank researchers from Computational and Biological Laboratory at Cambridge University for their feedback on an early version of the post.</em>
+<!----- Footnotes -----></p>
+:ET

docs/.jekyll-cache/Jekyll/Cache/Jekyll--Converters--Markdown/0f/51061f1e9b01da22a7c80634ec1094933331a4b168861457ca91604ab79bdf

@@ -0,0 +1,2 @@
+I"
�<p>Turing’s modelling syntax allows you to specify a model quickly and easily. Straightforward models can be expressed in the same way as complex, hierarchical models with stochastic control flow.</p>
+:ET

docs/.jekyll-cache/Jekyll/Cache/Jekyll--Converters--Markdown/12/2d39f063f9b701aec63806d480893517c25a3363d33efb919e78508fb1bade

@@ -0,0 +1,25 @@
+I".<p>Last year, Turing participated in the Google Summer of Code (GSoC) through the Julia language organization. It was a fun time, and the project was better for it. Turing plans to participate in the upcoming GSoC, and we wanted to outline some potential projects and expectations we have for applicants.</p>
+
+<p>If you are not aware, Google provides funds to students around the world to develop a project of their choice over the summer. Students receive funds from Google and spend three months on any open source project.</p>
+
+<p>The Turing development team has prepared a list of possible projects that we have deemed valuable to the project and easy enough that it could feasibly be created in the three-month limit. This list is not exlusive – if you have a good idea, you can write it up in your proposal, though it is recommend that you reach out to any of the Turing team on Julia’s <a href="https://julialang.slack.com/">Slack</a> (you can get an invite <a href="https://slackinvite.julialang.org/">here</a>) or <a href="https://discourse.julialang.org/c/domain/probprog">Discourse</a>. Messages on Discourse should be posted to the “Probabilistic programming” category – we’ll find you!</p>
+
+<p>Possible project ideas:</p>
+
+<ul>
+  <li><strong>Benchmarking</strong>. Turing’s performance has been sporadically benchmarked against various other probabilistic programming languages (e.g. Turing, Stan, PyMC3, TensorFlow Prob), but a systemic approach to studying where Turing excels and where it falls short would be useful. A GSoC student would implement identical models in many PPLs and build tools to benchmark all PPLs against one another.</li>
+  <li><strong>Nested sampling integration</strong>. Turing focuses on modularity in inference methods, and the development team would like to see more inference methods, particularly the popular nested sampling method. A Julia package (<a href="https://github.com/mileslucas/NestedSamplers.jl">NestedSamplers.jl</a>) but it is not hooked up to Turing and does not currently have a stable API. A GSoC student would either integrate that package or construct their own nested sampling method and build it into Turing.</li>
+  <li><strong>Automated function memoization by model annotation</strong>. Function memoization is a way to reduce costly function evaluation by caching the output when the same inputs are given. Turing’s Gibbs sampler often ends up <a href="https://turing.ml/dev/docs/using-turing/performancetips#reuse-computations-in-gibbs-sampling">rerunning expensive functions</a> multiple times, and it would be a significant performance improvement to allow Turing’s model compiler to automatically memoize functions where appropriate. A student working on this project would become intimately familiar with Turing’s model compiler and build in various automated improvements.</li>
+  <li><strong>Making Distributions GPU compatible</strong>. Julia’s GPU tooling is generally quite good, but currently Turing is not able to reliably use GPUs while sampling because <a href="https://github.com/JuliaStats/Distributions.jl">Distributions.jl</a> is not GPU compatible. A student on this project would work with the Turing developers and the Distributions developers to allow the use of GPU parallelism where possible in Turing.</li>
+  <li><strong>Static distributions</strong>. Small, fixed-size vectors and matrices are fairly common in Turing models. This means that sampling in Turing can probably benefit from using statically sized vectors and matrices from <a href="https://github.com/JuliaArrays/StaticArrays.jl">StaticArrays.jl</a> instead of the dynamic normal Julia arrays. Beside the often superior performance of small static vectors and matrices, static arrays are also automatically compatible with the GPU stack in Julia. Currently, the main obstacle to using StaticArrays.jl is that distributions in <a href="https://github.com/JuliaStats/Distributions.jl">Distributions.jl</a> are not compatible with StaticArrays. A GSoC student would adapt the multivariate and matrix-variate distributions as well as the univariate distribution with vector parameters in Distributions.jl to make a spin-off package called StaticDistributions.jl. The student would then benchmark StaticDistributions.jl against Distributions.jl and showcase an example of using StaticDistributions.jl together with <a href="https://github.com/JuliaGPU/CuArrays.jl">CuArrays.jl</a> and/or <a href="https://github.com/JuliaGPU/CUDAnative.jl">CUDAnative.jl</a> for GPU-acceleration.</li>
+  <li><strong>GPnet extensions</strong>. One of Turing’s sattelite packages, <a href="https://github.com/TuringLang/GPnet.jl">GPnet</a>, is designed to provide a comprehensive suite of Gaussian process tools. See <a href="https://github.com/TuringLang/GPnet.jl/issues/2">this issue</a> for potential tasks – there’s a lot of interesting stuff going on with GPs, and this task in particular may have some creative freedom to it.</li>
+  <li><strong>Better chains and model diagnostics</strong>. One package that Turing (and many others) rely on heavily is <a href="https://github.com/TuringLang/MCMCChains.jl">MCMCChains.jl</a>, a package designed to format, store, and analyze parameter samples generated during MCMC inference. MCMCChains is currently showing its age a little and has many <a href="https://github.com/TuringLang/MCMCChains.jl/issues/171">bad design choices</a> that need to be fixed. Alternatively, a student could contstruct a far more lightweight chain system.</li>
+  <li><strong>Model comparison tools</strong>. Turing and its sattelite packages do not currently provide a comprehensive suite of model comparison tools, a critical tool for the applied statistician. A student who worked on this project would implement various model comparison tools like <a href="https://mc-stan.org/loo/">LOO and WAIC</a>, among others.</li>
+  <li><strong>MLE/MAP tools</strong>. <a href="https://en.wikipedia.org/wiki/Maximum_likelihood_estimation">Maximum likelihood estimates</a> (MLE) and <a href="https://en.wikipedia.org/wiki/Maximum_a_posteriori_estimation">maximum a posteriori</a> (MAP) estimates can currently only be done by users through a <a href="https://turing.ml/dev/docs/using-turing/advanced#maximum-a-posteriori-estimation">clunky set of workarounds</a>. A streamlined function like <code class="language-plaintext highlighter-rouge">mle(model)</code> or <code class="language-plaintext highlighter-rouge">map(model)</code> would be very useful for many of Turing’s users who want to see what the MLE or MAP estimates look like, and it may be valuable to allow for functionality that allows MCMC sampling to begin from the MLE or MAP estimates. Students working on this project will work with optimization packages such as <a href="https://github.com/JuliaNLSolvers/Optim.jl">Optim.jl</a> to make MLE and MAP estimation straightforward for Turing models.</li>
+  <li><strong>Particle sampler improvements</strong>. Turing’s development team has spent a lot of time and energy to make inference methods more modular, but Turing’s particle samplers have not yet been modernized and spun off into a separate package. Two packages that resulted from this were <a href="https://github.com/TuringLang/AdvancedHMC.jl">AdvancedHMC</a> for Hamiltonian MCMC methods, and <a href="https://github.com/TuringLang/AdvancedMH.jl">AdvancedMH</a> for Metropolis-Hastings style inference methods. A student who worked on this project would become very familiar with Turing’s inference backend and with particle sampling methods. This is a good project for people who love making things efficient and easily extendable.</li>
+</ul>
+
+<p>Other projects are welcome, but we do strongly recommend discussing any potential projects with members of the Turing team, as they will end up mentoring GSoC students for the duration of the project.</p>
+
+<p>We’re looking forward to what people are interested in!</p>
+:ET