Merge branch 'add_notebook_dl' of github.com:TuringLang/docs into add_notebook_dl

Author: Aoife

_quarto.yml

@@ -134,6 +134,8 @@ website:
               - developers/inference/variational-inference/index.qmd
               - developers/inference/implementing-samplers/index.qmd
 
+        - faq/index.qmd
+
   back-to-top-navigation: true
   repo-url: https://github.com/TuringLang/docs
   repo-actions: [edit, issue]

core-functionality/index.qmd

@@ -52,6 +52,7 @@ These respectively correspond to likelihood and prior terms.
 
 It is easier to start by explaining when a variable is treated as an observed value.
 This can happen in one of two ways:
+
 - The variable is passed as one of the arguments to the model function; or
 - The value of the variable in the model is explicitly conditioned or fixed.
 

developers/inference/abstractmcmc-turing/index.qmd

@@ -262,7 +262,7 @@ $$
 
 with $\theta_{\text{prop}}$ a sample from the proposal and $x_{\text{obs}}$ the observed data.
 
-This begs the question: how can these functions access model information during sampling? Recall that the model is stored as an instance `m` of `Model`. One of the attributes of `m` is the model evaluation function `m.f`, which is built by compiling the `@model` macro. Executing `f` runs the tilde statements of the model in order, and adds model information to the sampler (the instance of `Sampler` that stores information about the ongoing sampling process) at each step (see [here](https://turinglang.org/dev/docs/for-developers/compiler) for more information about how the `@model` macro is compiled). The DynamicPPL functions `assume` and `observe` determine what kind of information to add to the sampler for every tilde statement.
+This begs the question: how can these functions access model information during sampling? Recall that the model is stored as an instance `m` of `Model`. One of the attributes of `m` is the model evaluation function `m.f`, which is built by compiling the `@model` macro. Executing `f` runs the tilde statements of the model in order, and adds model information to the sampler (the instance of `Sampler` that stores information about the ongoing sampling process) at each step (see [here]({{<meta dev-model-manual>}}) for more information about how the `@model` macro is compiled). The DynamicPPL functions `assume` and `observe` determine what kind of information to add to the sampler for every tilde statement.
 
 Consider an instance `m` of `Model` and a sampler `spl`, with associated `VarInfo` `vi = spl.state.vi`. At some point during the sampling process, an AbstractMCMC function such as `step!` calls  `m(vi, ...)`, which calls the model evaluation function `m.f(vi, ...)`.
 

faq/index.qmd

@@ -41,6 +41,7 @@ sample(m2, NUTS(), 100) # This doesn't work!
 The key insight is that `filldist` creates a single distribution (not N independent distributions), which is why you cannot condition on individual elements. The distinction is not just about what appears on the LHS of `~`, but whether you're dealing with separate distributions (`.~` with univariate) or a single distribution over multiple values (`~` with multivariate or `filldist`).
 
 To understand more about how Turing determines whether a variable is treated as random or observed, see:
+
 - [Core Functionality]({{< meta core-functionality >}}) - basic explanation of the `~` notation and conditioning
 
 
@@ -50,10 +51,11 @@ Yes, but with important caveats! There are two types of parallelism to consider:
 
 ### 1. Parallel Sampling (Multiple Chains)
 Turing.jl fully supports sampling multiple chains in parallel:
+
 - **Multithreaded sampling**: Use `MCMCThreads()` to run one chain per thread
 - **Distributed sampling**: Use `MCMCDistributed()` for distributed computing
 
-See the [Core Functionality guide]({{< meta core-functionality >}}/#sampling-multiple-chains) for examples.
+See the [Core Functionality guide]({{<meta core-functionality>}}#sampling-multiple-chains) for examples.
 
 ### 2. Threading Within Models
 Using threads inside your model (e.g., `Threads.@threads`) requires more care:
@@ -69,6 +71,7 @@ end
 ```
 
 **Important limitations:**
+
 - **Observe statements**: Generally safe to use in threaded loops
 - **Assume statements** (sampling statements): Often crash unpredictably or produce incorrect results
 - **AD backend compatibility**: Many AD backends don't support threading. Check the [multithreaded column in ADTests](https://turinglang.org/ADTests/) for compatibility
@@ -78,12 +81,14 @@ For safe parallelism within models, consider vectorized operations instead of ex
 ## How do I check the type stability of my Turing model?
 
 Type stability is crucial for performance. Check out:
+
 - [Performance Tips]({{< meta usage-performance-tips >}}) - includes specific advice on type stability
 - Use `DynamicPPL.DebugUtils.model_warntype` to check type stability of your model
 
 ## How do I debug my Turing model?
 
 For debugging both statistical and syntactical issues:
+
 - [Troubleshooting Guide]({{< meta usage-troubleshooting >}}) - common errors and their solutions
 - For more advanced debugging, DynamicPPL provides [the `DynamicPPL.DebugUtils` module](https://turinglang.org/DynamicPPL.jl/stable/api/#Debugging-Utilities) for inspecting model internals
 
@@ -125,16 +130,18 @@ end
 ## Which automatic differentiation backend should I use?
 
 The choice of AD backend can significantly impact performance. See:
+
 - [Automatic Differentiation Guide]({{< meta usage-automatic-differentiation >}}) - comprehensive comparison of ForwardDiff, Mooncake, ReverseDiff, and other backends
 - [Performance Tips]({{< meta usage-performance-tips >}}#choose-your-ad-backend) - quick guide on choosing backends
 - [AD Backend Benchmarks](https://turinglang.org/ADTests/) - performance comparisons across various models
 
 ## I changed one line of my model and now it's so much slower; why?
 
 Small changes can have big performance impacts. Common culprits include:
+
 - Type instability introduced by the change
 - Switching from vectorized to scalar operations (or vice versa)
 - Inadvertently causing AD backend incompatibilities
 - Breaking assumptions that allowed compiler optimizations
 
-See our [Performance Tips]({{< meta usage-performance-tips >}}) and [Troubleshooting Guide]({{< meta usage-troubleshooting >}}) for debugging performance regressions.
+See our [Performance Tips]({{< meta usage-performance-tips >}}) and [Troubleshooting Guide]({{< meta usage-troubleshooting >}}) for debugging performance regressions.

tutorials/bayesian-differential-equations/index.qmd

@@ -85,6 +85,7 @@ To make the example more realistic, we generate data as random Poisson counts ba
 Poisson-distributed data are common in ecology (for instance, counts of animals detected by a camera trap).
 We'll assume that the rate $\lambda$, which parameterizes the Poisson distribution, is proportional to the underlying animal densities via a constant factor $q = 1.7$.
 
+
 ```{julia}
 sol = solve(prob, Tsit5(); saveat=0.1)
 q = 1.7
@@ -111,11 +112,12 @@ Practically, this helps us to illustrate the results without needing to run over
 Note we also have to take special care with the ODE solver.
 For certain parameter combinations, the numerical solver may predict animal densities that are just barely below zero.
 This causes errors with the Poisson distribution, which needs a non-negative mean $\lambda$.
-To avoid this happening, we tell the solver to aim for small abolute and relative errors (`abstol=1e-6, reltol=1e-6`).
+To avoid this happening, we tell the solver to aim for small absolute and relative errors (`abstol=1e-6, reltol=1e-6`).
 We also add a fudge factor `ϵ = 1e-5` to the predicted data.
 Since `ϵ` is greater than the solver's tolerance, it should overcome any remaining numerical error, making sure all predicted values are positive.
 At the same time, it is so small compared to the data that it should have a negligible effect on inference.
 If this approach doesn't work, there are some more ideas to try [here](https://docs.sciml.ai/DiffEqDocs/stable/basics/faq/#My-ODE-goes-negative-but-should-stay-positive,-what-tools-can-help?).
+In the case of continuous observations (e.g. data derived from modelling chemical reactions), it is sufficient to use a normal distribution with the mean as the data point and an appropriately chosen variance (which can itself also be a parameter with a prior distribution).
 
 ```{julia}
 @model function fitlv(data, prob)

tutorials/bayesian-logistic-regression/index.qmd

@@ -155,7 +155,7 @@ chain
 ::: {.callout-warning collapse="true"}
 ## Sampling With Multiple Threads
 The `sample()` call above assumes that you have at least `nchains` threads available in your Julia instance. If you do not, the multiple chains 
-will run sequentially, and you may notice a warning. For more information, see [the Turing documentation on sampling multiple chains.](https://turinglang.org/dev/docs/using-turing/guide/#sampling-multiple-chains)
+will run sequentially, and you may notice a warning. For more information, see [the Turing documentation on sampling multiple chains.]({{<meta core-functionality>}}#sampling-multiple-chains)
 :::
 
 ```{julia}

tutorials/bayesian-poisson-regression/index.qmd

@@ -175,7 +175,7 @@ chain
 ::: {.callout-warning collapse="true"}
 ## Sampling With Multiple Threads
 The `sample()` call above assumes that you have at least `nchains` threads available in your Julia instance. If you do not, the multiple chains 
-will run sequentially, and you may notice a warning. For more information, see [the Turing documentation on sampling multiple chains.](https://turinglang.org/dev/docs/using-turing/guide/#sampling-multiple-chains)
+will run sequentially, and you may notice a warning. For more information, see [the Turing documentation on sampling multiple chains.]({{<meta core-functionality>}}#sampling-multiple-chains)
 :::
 
 # Viewing the Diagnostics