Skip to content

Add FAQ section to improve user guidance #608

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions _quarto.yml
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,8 @@ website:
text: Get Started
- href: tutorials/coin-flipping/
text: Tutorials
- href: faq/
text: FAQ
- href: https://turinglang.org/library/
text: Libraries
- href: https://turinglang.org/news/
Expand Down
72 changes: 72 additions & 0 deletions faq/index.qmd
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
---
title: "Frequently Asked Questions"
description: "Common questions and answers about using Turing.jl"
---

## Why is this variable being treated as random instead of observed?

This is a common source of confusion. In Turing.jl, you can only manipulate expressions that explicitly appear on the left-hand side (LHS) of a `~` statement.

For example, if your model contains:
```julia
x ~ filldist(Normal(), 2)
```

You cannot directly condition on `x[2]` using `condition(model, @varname(x[2]) => 1.0)` because `x[2]` never appears on the LHS of a `~` statement. Only `x` as a whole appears there.

To understand more about how Turing determines whether a variable is treated as random or observed, see:
- [Compiler Design Overview](../developers/compiler/design-overview/) - explains the heuristics Turing uses
- [DynamicPPL Transformations](../developers/transforms/dynamicppl/) - details about variable transformations and the `@varname` macro
- [Core Functionality](../core-functionality/) - basic explanation of the `~` notation and conditioning

## How do I implement a sampler for a Turing.jl model?

We have comprehensive guides on implementing custom samplers:
- [Implementing Samplers Tutorial](../developers/inference/implementing-samplers/) - step-by-step guide on implementing samplers in the AbstractMCMC framework
- [AbstractMCMC-Turing Interface](../developers/inference/abstractmcmc-turing/) - how to integrate your sampler with Turing
- [AbstractMCMC Interface](../developers/inference/abstractmcmc-interface/) - the underlying interface documentation

## Can I use parallelism / threads in my model?

Yes! Turing.jl supports both multithreaded and distributed sampling. See the [Core Functionality guide](../core-functionality/#sampling-multiple-chains) for detailed examples showing:
- Multithreaded sampling using `MCMCThreads()`
- Distributed sampling using `MCMCDistributed()`

## How do I check the type stability of my Turing model?

Type stability is crucial for performance. Check out:
- [Performance Tips](../usage/performance-tips/) - includes specific advice on type stability
- [Automatic Differentiation](../usage/automatic-differentiation/) - contains benchmarking utilities using `DynamicPPL.TestUtils.AD`

## How do I debug my Turing model?

For debugging both statistical and syntactical issues:
- [Troubleshooting Guide](../usage/troubleshooting/) - common errors and their solutions
- For more advanced debugging, DynamicPPL provides `DynamicPPL.DebugUtils` for inspecting model internals

## What are the main differences between Turing vs BUGS vs Stan syntax?

While there are many syntactic differences, key advantages of Turing include:
- **Julia ecosystem**: Full access to Julia's profiling and debugging tools
- **Parallel computing**: Much easier to use distributed and parallel computing inside models
- **Flexibility**: Can use arbitrary Julia code within models
- **Extensibility**: Easy to implement custom distributions and samplers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't answer the stated question?

If it's a question about syntax, I would personally think it's best to have Turing vs Stan in a single section, and Turing vs (other PPL) can be a different section. Apart from the parameter block, two of the common things that Stan models have that Turing doesn't are transformed data and generated quantities -- the gist in Turing is that any data transformations should be done before defining the model (so it's decoupled from the model) and generated quantities are covered in https://turinglang.org/docs/usage/tracking-extra-quantities/index.html.


## Which automatic differentiation backend should I use?

The choice of AD backend can significantly impact performance. See:
- [Automatic Differentiation Guide](../usage/automatic-differentiation/) - comprehensive comparison of ForwardDiff, Mooncake, ReverseDiff, and other backends
- [Performance Tips](../usage/performance-tips/#choose-your-ad-backend) - quick guide on choosing backends
- [AD Backend Benchmarks](https://turinglang.org/ADTests/) - performance comparisons across various models

For more specific recommendations, check out the [DifferentiationInterface.jl tutorial](https://juliadiff.org/DifferentiationInterface.jl/DifferentiationInterfaceTest/stable/tutorial/).

## 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](../usage/performance-tips/) and [Troubleshooting Guide](../usage/troubleshooting/) for debugging performance regressions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you took the list questions from somewhere else, but I don't really like this question. I don't get the intent behind it (what is the answer supposed to be?) and the result of this is, I think, reflected in the text, which is very vague and IMO not very helpful. If the answer is basically to read the performance section.

IME interactions with AD backend don't often lead to performance differences, usually it either runs fine or it crashes. If the AD is unusually slow it usually reflects slowness in the model itself.