devmotion
commented
3 years ago I'd benchmark all approaches and then choose the fastest 😉 More seriously, it's really problem and model dependent.
Maybe another alternative would be to break up the priors (and p) into multiple groups with thr same type of prior since the problems arise from priors not being concretely typed.
Alternatively, maybe you can add a type assertion on p such as p::Vector{Float64} (I guess Turing might not support this) or with an additional variable _p::Vector{Float64} = p that you use then in the ODE solver. BTW if I'm not mistaken, your type annotations such as ::Array... in the function body are basically equivalent to convert calls but for actual type assertions (that error if not satisfied and are guarantees to the compiler) you have to annotate the assigned variable, i.e., something like x::Vector{Float64} = .... The annotation ::ODEProblem is probably not helpful since ODEProblem is not a concrete type (generally, the output of remake should be inferrable if the inputs such as pare inferred). However, IIRC you can just call solve(prob1, Tsit5(); p=p, saveat=0.1) (or with p=_p) without constructing prob explicitly. The Bayesian DiffEq tutorial also contains examples of how to set the sensitivity mode and AD system of the ODE solver (which is independent from the Turing settings).
ClaudMor
Hello,
Following the performance tips, I'm trying to let the compiler know all types in my turing model in advance.
Anyway, I'm facing problems trying to make it infer the type of arrays ( here
p) that appear inside the model in the formWhat follows is a more explicit example inspired by the tutorials, modified to reflect the structure of the more complex model I'm trying to build.
Then if I inspect the type inference, I get:
( I did my best trying to color the text as
@code_warntypewould, with the caveat that if a line is colored, then @code_warntype would have colored only the type after the::. I didn't color all lines not to ruin indentation, since I'm using this trick to color the text. I just colored the first ones )So how may i fix the type inference?
I know that I could be using a for loop instead of the
arraydistas seen here, but the model we are developing is a bit complicated ( ~ 60 parameters), so it may benefit from switching toTrackerADorZygotebackend, which doesn't like loops.Side question: in case we had to choose between
TrackerADorZygoteTrackerADorZygoteReverseDiffWhich would you suggest?
Thank you very much for your attention.