Hmmm. It does not sound like intended behavior. My best guess is that threading is making it difficult to calculate the expected finish time. It might be worth opening an issue at Turing and including a minimum working example.
I think that if you sample multiple chains using MCMCThreads
then the progress bar shows how many chains already finished. Therefore if you sample 4 chains you will only get values of 25, 50, and 75 percent. The relevant code in Turing is here. So I think this is the intended behaviour. You might want to open an issue/discussion in Turing about whether it would be possible to change this behaviour.
That makes sense. An alternative approach might show a progress bar for each chain. It would provide more detail about the progress of the sampler. I don’t know if that is feasible with threads though.
We’ve had lots of discussion about how to modify this behavior, and I think the consensus is that it is difficult to do well, so we’ve opted towards simpler and perhaps misleading solutions. I would like to see separate bars for each chain but right now it’s not a high priority.
I think the challenge is printing the updates to the same line. In this example, each update is given a new line:
using ProgressMeter
import Base.Threads.@threads
function fun()
@showprogress for i in 1:100
sleep(.01)
end
end
@threads for i in 1:4
fun()
end
I believe that this used to be the behavior in Turing at one point.
@drbenvincent In MeasureTheory.jl we have different ways to parameterize things, so logistic or probit regression should become easier to write, and hopefully faster too. So in Soss (or other things that use MeasureTheory) you’ll be able to write your likelihood as
sᵇ ~ For(ϕᵇ) do z Binomial(n = nᵇ, probit_p = z) end
sⁿ ~ For(ϕⁿ) do z Binomial(n = nⁿ, probit_p = z) end
The posterior sampling isn’t working for me right now with Zygote, but I think maybe that’s more of an AD issue than a modeling issue.
Nice. Soss is definitely on my list of things to look at. Just a matter of time!