-
Notifications
You must be signed in to change notification settings - Fork 33
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
Making dimensionality part of the Bijector type #44
Conversation
563e50a
to
3e06541
Compare
3e06541
to
589e564
Compare
Btw, I think it would be a good idea to separate implementations of I have several new bijectors in the pipeline and IMO such a project structure makes much more sense as the number of bijectors grows. Question: should I include this in this PR or do it in a separate PR? |
Definitely
I'm fine if you do it in this PR. But you might need to resolve some conflicts to make other PRs merge afterwards. |
Then I'll do that. And yeah, but probably going to have to do that anyways!:) |
Actually, let's just get this thing merged and then we can do that after. There's so much work that depends on this PR that I'd like to just get it merged asap |
There some conflicts need to be resolved. After that is solved I'm happy to merge it given CI passes. |
The only faild CIs are in the nightly Julia version. I guess it's fine to merge it now. I will do so before I sleep if no objection. |
Yeah, from a quick look at the logs it seems like it's an issue with Tracker.jl rather than us so will probably be resolved in the future by updating deps. |
Overview
This PR attempts to solve #35 by introducing the dimensionality of input/output (the same)
N
into theBijector
type.Pros:
Bijector
support for batch computation #35Bijector{N}
are only well-defined for a specific value ofN
, so in these cases the only change necessary is, say,Specific1DBijector <: Bijector
→Specific1DBijector <: Bijector{1}
. E.g.SimplexBijector
is only well-defined for vector input, soSimplexBijector <: Bijector{1}
. To get a quick overview of the differences from a user-perspective, have a look at the diff fortests/interface.jl
. There's barely any change.Cons:
Log()
looks nicer thanLog{0}()
, etc. But again, due to (3) in pros this is in most cases not a huge issue from a user perspective.To-be discussed
Bijector
since it requires explicit implementation oflogabsdetjac
for both standard case and the batch computation. But of course if the user doesn't want batch-computation, then there's no more work than before.Bijector
? Could people want to implement something more general than just standardReal
orAbstractArray
, and this prohibits it? If so, is this of any priority to us?TODOs