You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Things we can implement using contexts, i.e. use-cases to motivate better handling of "compositions" or "interplay" of contexts, i.e. PLEASE CAN WE REVISIT #254 OR SOME OTHER VERSION OF IT, I'M DYING OVER HERE.
Anyways:
ConditionContext: allows specifying certain variables that are considered observations rather than assumptions, or even forcing observations to be considered missing/assumptions.
Following features are then trivial:
condition/decondition of a Model (if we introduce a ContextualModel which is just a pair of Context and Model), which in turn makes other contexts such as PriorContext and LikelihoodContext completely redundant.
DistributionReplacementContext: allows replacement of distributions passed through the tilde-pipeline.
Following features are then trivial:
Automatic reparameterizations, e.g. somewhere in the pipeline we just replace the non-centered distribution with the centered one and apply the corresponding transformation on the resulting sample.
Performance-improvements. Often Distributions.jl's impl isn't the best, especially when combined with AD. Sure, we can just use @addlogprob!, etc., but this is annoying for users compared to just going optimize_distributions(model) or something and it just replaces distributions with nicer evaluators.
SymbolicContext: allows using Symbolics.jl to trace through the model, thus opening up an entire new box of sweets! Working example is here Making use of Symbolics.jl/SymbolicUtils.jl #234, but it doesn't work well when used together with other contexts.
Following features are then trivial (for a lot of models):
DAG-extraction.
Symbolic generation of logdensity-computation.
Symbolic generation of gradient of logdensity-computation.
Simplifications.
And so much more.
CUDAContext: makes it possible to execute the model on GPU. This is similar in nature to DistributionReplacementContext.
Following features are then trivial:
CUDA support (duh).
And all of these contexts can be hidden behind nicer functions a la condition.
So why do I have tears of sadness in my eyes you ask? Well, as things are currently, contexts do not work well together (I rave on and on about this in #249). E.g. if we introduced a ConditionContext, we want this to work well with MiniBatchContext, PrefixContext, etc., and also the more "lower-level" contexts such as DefaultContext and Turing.OptimizationContext. The same thing holds for SymbolicContext (which we also want to work in tandem with ConditionContext), CUDAContext, etc.
And you know the best part about all of this? Once we have some general handling of interactions between contexts, all of these contexts can be introduced independently of eachother without breaking any existing code! This makes it soooo much easier to go from "hey CUDA-support is a neat idea" to actually implementing it.
When we last spoke about this, the decision was to not do so at the time because the use-cases not clear enough + I mixed some ideas together, thus muddling the main-point: better handling of interactions between contexts makes introduction of new features much, much easier:)
So, I created this issue so we can rejuvenate the discussions + keep better track of what we're missing, why we want it, what are the issues, etc. rather than in a PR (as was done in #249).
The text was updated successfully, but these errors were encountered:
Things we can implement using contexts, i.e. use-cases to motivate better handling of "compositions" or "interplay" of contexts, i.e. PLEASE CAN WE REVISIT #254 OR SOME OTHER VERSION OF IT, I'M DYING OVER HERE.
Anyways:
ConditionContext
: allows specifying certain variables that are considered observations rather than assumptions, or even forcing observations to be consideredmissing
/assumptions.condition
/decondition
of aModel
(if we introduce aContextualModel
which is just a pair ofContext
andModel
), which in turn makes other contexts such asPriorContext
andLikelihoodContext
completely redundant.missings
in aModel
does not propagate to a submodel #273DistributionReplacementContext
: allows replacement of distributions passed through the tilde-pipeline.@addlogprob!
, etc., but this is annoying for users compared to just goingoptimize_distributions(model)
or something and it just replaces distributions with nicer evaluators.SymbolicContext
: allows using Symbolics.jl to trace through the model, thus opening up an entire new box of sweets! Working example is here Making use of Symbolics.jl/SymbolicUtils.jl #234, but it doesn't work well when used together with other contexts.CUDAContext
: makes it possible to execute the model on GPU. This is similar in nature toDistributionReplacementContext
.And all of these contexts can be hidden behind nicer functions a la
condition
.So why do I have tears of sadness in my eyes you ask? Well, as things are currently, contexts do not work well together (I rave on and on about this in #249). E.g. if we introduced a
ConditionContext
, we want this to work well withMiniBatchContext
,PrefixContext
, etc., and also the more "lower-level" contexts such asDefaultContext
andTuring.OptimizationContext
. The same thing holds forSymbolicContext
(which we also want to work in tandem withConditionContext
),CUDAContext
, etc.And you know the best part about all of this? Once we have some general handling of interactions between contexts, all of these contexts can be introduced independently of eachother without breaking any existing code! This makes it soooo much easier to go from "hey CUDA-support is a neat idea" to actually implementing it.
When we last spoke about this, the decision was to not do so at the time because the use-cases not clear enough + I mixed some ideas together, thus muddling the main-point: better handling of interactions between contexts makes introduction of new features much, much easier:)
So, I created this issue so we can rejuvenate the discussions + keep better track of what we're missing, why we want it, what are the issues, etc. rather than in a PR (as was done in #249).
The text was updated successfully, but these errors were encountered: