-
Notifications
You must be signed in to change notification settings - Fork 104
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
978017b
d9a46e3
41ab37b
2b97c35
6ec9c7e
571c44a
6c6e32f
d231882
886429e
8734528
3a15298
85ecfbc
2726c1a
8cdc3c7
e864d7d
1c72064
6afff59
27a7f0f
883e269
700b77a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
|
||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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 | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- [DynamicPPL Transformations](../developers/transforms/dynamicppl/) - details about variable transformations and the `@varname` macro | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- [Core Functionality](../core-functionality/) - basic explanation of the `~` notation and conditioning | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## 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 | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## 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()` | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## 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` | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## 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 | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## What are the main differences between Turing vs BUGS vs Stan syntax? | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
|
||
## 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/). | ||
AoifeHughes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
Uh oh!
There was an error while loading. Please reload this page.