David Widmann

> Found this interesting kernel in the Probabilistic numerics textbook. Haha, I just started to read through that book a bit some weeks ago :smile: I'm not sure though if...

Generally, I feel the general use of `ThreadSafeVarInfo` with non-mutable varinfo objects probably is broken and should maybe be disallowed. Everytime different threads would call any of the `!!` methods...

Maybe one should a test in this package?

This was fixed in https://github.com/JuliaMath/AbstractFFTs.jl/pull/65 which is about to be released in AbstractFFTs 1.2.0 (https://github.com/JuliaRegistries/General/pull/63431). There is a function `fftdims` now that can be used to access the transformed region....

The variables are not sorted in recent Turing versions by default: https://github.com/TuringLang/Turing.jl/pull/1627 Which Turing version did you use?

Yeah but in the original comment above you just copied the output from the webpage (https://turing.ml/dev/tutorials/10-bayesian-differential-equations/), didn't you? And there a quite old version of Turing was used (0.15.18 apparently)...

As explained in https://github.com/TuringLang/Turing.jl/pull/1627, you can recover the old behaviour (sorting with natural sort order) by specifying `sort_chain=true` (i.e., use `sample(....; sort_chain=true)`). Alternatively, you can just use `2:5` instead of...

I guess the main issue is that you have many more choices in Turing/Julia to compute gradients than in Stan (and of course some samplers don't use gradients at all)....

Completely unrelated comment: you should specify `save_idxs` as a keyword argument to `solve`.

If you know the solution (such as e.g. for linear SDEs) and want to exploit it, probably the easiest thing to do (right now) is to use the explicit solutions...