Remove 3-argument {_,}evaluate!!; clean up submodel code
#960
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
penelopeysm
changed the title
_evaluate!!; clean up submodel code{_,}evaluate!!; clean up submodel code
penelopeysm
force-pushed
the
py/no-context-evaluate-submodel
branch
from
3dc22f4 to
4bb2526
Compare
Benchmark Report for Commit bfa48b3Computer InformationBenchmark Results |
penelopeysm
force-pushed
the
py/no-context-evaluate-submodel
branch
from
4bb2526 to
55f838f
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## breaking #960 +/- ##
============================================
- Coverage 82.85% 82.76% -0.09%
============================================
Files 38 38
Lines 4031 4010 -21
============================================
- Hits 3340 3319 -21
Misses 691 691 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
penelopeysm
force-pushed
the
py/no-context-evaluate-submodel
branch
2 times, most recently
from
dcd5c9d to
31b0caa
Compare
|
DynamicPPL.jl documentation for PR #960 is available at: |
penelopeysm
force-pushed
the
py/no-context-evaluate-submodel
branch
from
31b0caa to
039a523
Compare
penelopeysm
force-pushed
the
py/no-context-evaluate-submodel
branch
from
039a523 to
bfa48b3
Compare
mhauru
reviewed
Jul 2, 2025
| @@ -31,11 +31,11 @@ This version therefore excises the context argument, and instead uses `model.con | |||
| The upshot of this is that many functions that previously took a context argument now no longer do. | |||
| There were very few such functions where the context argument was actually used (most of them simply took `DefaultContext()` as the default value). | |||
|
|
|||
| `evaluate!!(model, varinfo, ext_context)` is deprecated, and broadly speaking you should replace calls to that with `new_model = contextualize(model, ext_context); evaluate!!(new_model, varinfo)`. | |||
| `evaluate!!(model, varinfo, ext_context)` is removed, and broadly speaking you should replace calls to that with `new_model = contextualize(model, ext_context); evaluate!!(new_model, varinfo)`. | |||
There was a problem hiding this comment.
Is the call here to say that this was not used by many users, and thus fine to remove without deprecation? Just checking.
Comment on lines
-155
to
-160
| Under the hood, [`to_submodel`](@ref) makes use of the following method to indicate that the model it's wrapping is a model over its return-values rather than something else | ||
|
|
||
| ```@docs | ||
| returned(::Model) | ||
| ``` | ||
|
|
There was a problem hiding this comment.
returned is still exported, right? In that case, why not have it in the docs?
Comment on lines
-881
to
-891
| function AbstractPPL.evaluate!!( | ||
| model::Model, varinfo::AbstractVarInfo, context::AbstractContext | ||
| ) | ||
| Base.depwarn( | ||
| "The `context` argument to evaluate!!(model, varinfo, context) is deprecated.", | ||
| :dynamicppl_evaluate_context, | ||
| ) | ||
| new_ctx = combine_model_and_external_contexts(model.context, context) | ||
| model = contextualize(model, new_ctx) | ||
| return evaluate!!(model, varinfo) | ||
| end |
There was a problem hiding this comment.
Wasn't this deprecation added just a few weeks ago? Or am I mixing this with something else?
Comment on lines
-8
to
-27
| """ | ||
| Distributional | ||
|
|
||
| Abstract type for type indicating that something is "distributional". | ||
| """ | ||
| abstract type Distributional end | ||
|
|
||
| """ | ||
| should_auto_prefix(distributional) | ||
|
|
||
| Return `true` if the `distributional` should use automatic prefixing, and `false` otherwise. | ||
| """ | ||
| function should_auto_prefix end | ||
|
|
||
| """ | ||
| is_rhs_model(x) | ||
|
|
||
| Return `true` if the `distributional` is a model, and `false` otherwise. | ||
| """ | ||
| function is_rhs_model end |
There was a problem hiding this comment.
Was it the case that this was all put in place assuming it would be used in the future, and so far we haven't done anything with it?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR:
evaluate!!(model, varinfo, context)in the DynamicPPL codebase_evaluate!!(model, varinfo, context)as this method was only being used for submodelsIn return, it introduces:
_evaluate!!(submodel, varinfo, context, left). Yes, yes, I basically moved the implementation from one place to the other; but the whole point is that this was special-case behaviour that was only needed for submodels, so this at least makes it clearer.It also removes a lot of wrapper code for submodels. For example, we don't have this
ReturnedModelWrapperandSampleablething any more, instead, there's justSubmodelwhich wraps a model.I personally don't see the need for more than one layer of indirection for submodels (in terms of the data structure, the only difference between a submodel and a model is that the submodel carries information about whether it should be auto-prefixed). I had mucked around with this before in #815 and I didn't find any real problems with removing the wrappers there (in fact in that PR I went one step further and removed all wrappers, but that would have made it impossible to opt-out of prefixing and that's Bad(TM)).
I didn't add any new tests, but
test/submodel.jlalready contains quite extensive tests to make sure that everything behaves and it passes these tests so I'm quite happy.#959 needs to be merged first.Done.Follow-up from #952
Closes #720 (for good)