Skip to content
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

Rewrite: what do we want #211

Open
torfjelde opened this issue Dec 8, 2021 · 0 comments
Open

Rewrite: what do we want #211

torfjelde opened this issue Dec 8, 2021 · 0 comments

Comments

@torfjelde
Copy link
Member

torfjelde commented Dec 8, 2021

I'm just putting this here so that we know what to keep in mind when working on #183.

General

Cross-post of comment from @csherrer:

If there's refactoring in the works, here's my wishlist:

  • Not too Distributions-specific (though a dependency is no problem)
  • No requirement that dimensionality is constant (impossible in many cases)
  • Support for one-sided inverses (injections / surjections)
  • LADJ optional (e.g. doesn't apply for discrete measures)
  • No hard-coded type parameters. Real prevents symbolics, Int prevents static sizes
  • Callable transforms - no transform required for mapping points
  • Flattening should be optional, or maybe an intermediate form

I've also been thinking of using StrideArrays for intermediate representations, since allocations can have a lot of overhead. This is still in the pondering stage, and I guess for a lightweight dependency is a bit much. But maybe there can be an argument giving the array type? Most important IMO is not to disallow it by design.

Originally posted by @cscherrer in #199 (comment)

Handling batches/collections of inputs

The current idea is to generalize the approach taken by RowVecs and ColVecs from KernelFunctions.jl to handle more general storage, as discussed extensively in https://github.com/TuringLang/Bijectors.jl/discussions/178, by introducing a Batch and then providing general implementations which performs a naive map or something of the sort, while simultaneously allowing implementers to specialize batch-implementations for improved efficiency when it makes sense.

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

No branches or pull requests

1 participant