[Merged by Bors] - Some minor utility improvements #452
Conversation
This file contains 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
devmotion
reviewed
Jan 23, 2023
src/utils.jl
Outdated
| varname_leaves(vn::VarName, val) | ||
|
|
||
| Return iterator over all varnames that are represented by `vn` on `val`, | ||
| e.g. `varname_leaves(@varname(x), rand(2))` results in an iterator over `[@varname(x[1]), @varname(x[2])]`. |
There was a problem hiding this comment.
Maybe make this example a doctest?
| @@ -60,7 +60,7 @@ end | |||
| function LogDensityFunction( | |||
| model::Model, | |||
| varinfo::AbstractVarInfo=VarInfo(model), | |||
| context::AbstractContext=DefaultContext(), | |||
| context::AbstractContext=model.context, | |||
Co-authored-by: David Widmann <devmotion@users.noreply.github.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…DynamicPPL.jl into torfjelde/minor-improvements
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
devmotion
approved these changes
Jan 24, 2023
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Jan 25, 2023
This PR does the following: - Moves the `varname_leaves` from `TestUtils` to main module. - It can be very useful in Turing.jl for constructing `Chains` and the like, so I think it's a good idea to make it part of the main module rather than keeping it "hidden" there. - Makes the default `varinfo` in the constructor of `LogDensityFunction` be `model.context` rather than a new `DynamicPPL.DefaultContext`. - The `context` pass to `evaluate!!` will override the leaf-context in `model.context`, and so the current default constructor always uses `DefaultContext` as the leaf-context, even if the `Model` has been `contextualize`d with some other leaf-context, e.g. `PriorContext`. This PR fixes this issue.
|
Pull request successfully merged into master. Build succeeded: |
bors
bot
changed the title
yebai
added a commit
that referenced
this pull request
Mar 2, 2023
…eep existing compat) (#469) * Fixed a typo in tutorial (#451) * CompatHelper: bump compat for Turing to 0.24 for package turing, (keep existing compat) (#450) This pull request changes the compat entry for the `Turing` package from `0.21` to `0.21, 0.24` for package turing. This keeps the compat entries for earlier versions. Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Co-authored-by: Hong Ge <3279477+yebai@users.noreply.github.com> * Some minor utility improvements (#452) This PR does the following: - Moves the `varname_leaves` from `TestUtils` to main module. - It can be very useful in Turing.jl for constructing `Chains` and the like, so I think it's a good idea to make it part of the main module rather than keeping it "hidden" there. - Makes the default `varinfo` in the constructor of `LogDensityFunction` be `model.context` rather than a new `DynamicPPL.DefaultContext`. - The `context` pass to `evaluate!!` will override the leaf-context in `model.context`, and so the current default constructor always uses `DefaultContext` as the leaf-context, even if the `Model` has been `contextualize`d with some other leaf-context, e.g. `PriorContext`. This PR fixes this issue. * Always run CI (#453) I find the current `bors` workflow a bit tedious. Most of the time, I summon `bors` to see the CI results (see e.g. #438). Given that most `CI` tests are quick (< 10mins), we can always run them by default. The most time-consuming `IntegrationTests` is still run by `bors` to avoid excessive CI runs. * Compat with new Bijectors.jl (#454) This PR makes DPPL compatible with the changes to come in TuringLang/Bijectors.jl#214. Tests are passing locally. Closes #455 Closes #456 * Another Bijectors.jl compat bound bump (#457) * CompatHelper: bump compat for MCMCChains to 6 for package test, (keep existing compat) (#467) This pull request changes the compat entry for the `MCMCChains` package from `4.0.4, 5` to `4.0.4, 5, 6` for package test. This keeps the compat entries for earlier versions. Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Co-authored-by: Hong Ge <3279477+yebai@users.noreply.github.com> * CompatHelper: bump compat for AbstractPPL to 0.6 for package test, (keep existing compat) --------- Co-authored-by: Hong Ge <3279477+yebai@users.noreply.github.com> Co-authored-by: github-actions[bot] <compathelper_noreply@julialang.org> Co-authored-by: Tor Erlend Fjelde <tor.erlend95@gmail.com>
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 does the following:
varname_leavesfromTestUtilsto main module.Chainsand the like, so I think it's a good idea to make it part of the main module rather than keeping it "hidden" there.varinfoin the constructor ofLogDensityFunctionbemodel.contextrather than a newDynamicPPL.DefaultContext.contextpass toevaluate!!will override the leaf-context inmodel.context, and so the current default constructor always usesDefaultContextas the leaf-context, even if theModelhas beencontextualized with some other leaf-context, e.g.PriorContext. This PR fixes this issue.