-
Notifications
You must be signed in to change notification settings - Fork 561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement MVN.unsqueeze #2624
Merged
Merged
Implement MVN.unsqueeze #2624
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
498743d
fix expand implementation
saitcakmak 9eaecdc
cast to torch.Size
saitcakmak b37a85b
expand covar matrix
saitcakmak 0df1c55
implement MVN.unsqueeze
saitcakmak 312b0f1
add dim validation
saitcakmak 179a1b4
Merge branch 'main' into mvn_unsqueeze
saitcakmak File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of this is duplicate from the
expand()
code above. Can we make a helper to reuse most of this? Or potentially consider allowing to instantiate a new MVN from thescale_tril
directly as suggested on the other PR. Could be a class methodMultivariateNormal.from_scale_tril()
or the like if we don't want to change the__init__()
signature.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They follow the same pattern but I wouldn't call them duplicates. You could make a helper that takes in the operation to apply to the tensors, but there are two separate operations for
expand
(for loc & covar), so I don't know if the resulting helper would improve the code readability.This would avoid the issue of checking for
covar
&scale_tril
compatibility in__init__
. If we're not using__init__
, would this just extract theself.__new__
based construction used here into a separate method? I suppose this'd work for non-lazyscale_tril
as is. We'd have to have a separate case for lazy, at which point we end up with a duplicate of__init__
and I again question the added value of it over just keeping this as is.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we have a method exposed that allows constructing the MVN from
scale_tril
(either as part of an updated__init__()
method or as a separate method) then I would expect that people will see and use this for other purposes going forward (but they most likely won't look for the logic for this somewhere deep in the code as in this PR.Not going to die on that hill, but the fact that we don't expose a natural way of doing this seems like a gap we ideally could address.