Make FlexiChains the default chain type#2743
Conversation
|
Turing.jl documentation for PR #2743 is available at: |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2743 +/- ##
==========================================
- Coverage 85.40% 84.61% -0.80%
==========================================
Files 22 23 +1
Lines 1501 1514 +13
==========================================
- Hits 1282 1281 -1
- Misses 219 233 +14 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
c09ba13 to
76c1ccb
Compare
|
Thanks @sunxd3! Yeah, it is actually even more work than this. I need to transfer the extensions into Turing/DynamicPPL as well. That should hopefully just be a copypaste but I'm sure it will break something... |
|
I probably won't have the time to finish this up. (well, it seems it depends on whether I want to work on the weekend lol.) Sequence of events:
|
Mostly interested in seeing what breaks, I ran some tests offline then got bored.
As far as source code changes go, I only needed to change the definition of
DEFAULT_CHAIN_TYPEand twiddle with some imports. So in principle this is pretty much done.Most changes were really in the test suite, using
chn[@varname(x)]instead ofchn[:x]. In fact, that isn't even necessary, but I just consider it good practice.The only changes that I found to be mandatory were changing things like
chn[Symbol("m[1]")]tochn[@varname(m[1])], which is a Positive Change, and also other things that relied too heavily on the exact internal structure of MCMCChains, which is also a Positive Change, or a Neutral Change in the cases where I had to rely on the internal structure of FlexiChains.This PR should definitely target breaking, but that would cause version conflicts with FlexiChains, since FlexiChains has a compat entry that pins Turing to its current minor version. That can be fixed by moving FlexiChainsTuringExt into Turing proper, so that that compat entry can be removed.