Skip to content

Conversation

@torfjelde
Copy link
Member

This PR allows usage of Dict as the underlying storage in addition to the currently supported NamedTuple.

Similarly to SimpleVarInfo, this gives us two approaches: one with somewhat limited support, as outlined in the docstring, but with (usually) zero runtime overhead (NamedTuple), and one with full support but with runtime overead (Dict).

src/model.jl Outdated
Comment on lines 394 to 397
julia> deconditioned_model(rng) # (×) `m[1]` is still conditioned
2-element Vector{Float64}:
1.0
2.0
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that we could actually address this by introducing a DeconditionContext (can we maybe unify these?) that we'd fall back to if we can't locate the corresponding variable in existing ConditionContext

torfjelde and others added 3 commits July 28, 2022 17:45
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: David Widmann <[email protected]>
Co-authored-by: David Widmann <[email protected]>
@torfjelde
Copy link
Member Author

So I made an attempt at implementing the Gibbs sampler using condition with this PR, and one issue I ran into when testing on a model involving .~ is that the isassumption check happens with the LHS variable which is not a variable guaranteed to be present in the AbstractVarInfo. That is, the isassumption and AbstractVarInfo see different varnames, hence trying to use values in a varinfo to condition a model won't work in full generality.

We can address this, and I think there's an argument to be made for doing this anyways just to make sure that we see the same varnames everywhere.

We have to make

$vn = $(DynamicPPL.resolve_varnames)(
$(AbstractPPL.drop_escape(varname(left))), $right
)

instead use the "unwrapped" varnames that are passed to the tilde-pipeline

$(DynamicPPL.unwrap_right_left_vns)(
$(DynamicPPL.check_tilde_rhs)($right), $(maybe_view(left)), $vn
)...,

We should still have the same zero runtime overhead because the resulting varnames should be inferred correctly to Vector{<:VarName{sym}} and so we can just add impls for inargs and inmissings taking Vector{<:VarName{sym}} and performing the check at compile-time.

The only issue (but this is an issue nonetheless): NamedDist is still confusing. But a NamedDist has no purpose when used on something inargs anyways, unless combined with inmissings. So it's not that bad? 😕

@torfjelde
Copy link
Member Author

@devmotion would you be able to have another look at this now, or you still on vacation?

@yebai
Copy link
Member

yebai commented Aug 24, 2022

bors try

bors bot added a commit that referenced this pull request Aug 24, 2022
Copy link
Member

@yebai yebai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @torfjelde, @devmotion - nice generalisation of ConditionContext!


return canview(child, value)
end
Base.haskey(vi::SimpleVarInfo, vn::VarName) = nested_haskey(vi.values, vn)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice improvement!

2.0
julia> # (✓) this works though
deconditioned_model_2 = deconditioned_model | (@varname(m[1]) => missing);
Copy link
Member

@yebai yebai Aug 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarification question: would model_missing = model | (@varname(m[1]) => missing) work similiarly (i.e. m = [missing, 2.0])?

Return `true` if `vn` is found in `context`.
"""
hasvalue(context, vn) = false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that hasvalue should be unified with haskey. But perhaps this can be fixed in a future PR.

@yebai
Copy link
Member

yebai commented Aug 29, 2022

bors r+

bors bot pushed a commit that referenced this pull request Aug 29, 2022
This PR allows usage of `Dict` as the underlying storage in addition to the currently supported `NamedTuple`.

Similarly to `SimpleVarInfo`, this gives us two approaches: one with somewhat limited support, as outlined in the docstring, but with (usually) zero runtime overhead (`NamedTuple`), and one with full support but with runtime overead (`Dict`).
@yebai
Copy link
Member

yebai commented Aug 29, 2022

So I made an attempt at implementing the Gibbs sampler using condition with this PR, and one issue I ran into when testing on a model involving .~ is that the isassumption check happens with the LHS variable which is not a variable guaranteed to be present in the AbstractVarInfo. That is, the isassumption and AbstractVarInfo see different varnames, hence trying to use values in a varinfo to condition a model won't work in full generality.

It sounds good to me. We can probably open a PR to discuss this further.

@bors
Copy link
Contributor

bors bot commented Aug 29, 2022

@bors bors bot changed the title Condition with Dict as underlying storage [Merged by Bors] - Condition with Dict as underlying storage Aug 29, 2022
@bors bors bot closed this Aug 29, 2022
@bors bors bot deleted the tor/condition-with-dict branch August 29, 2022 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants