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.
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.
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:
Originally posted by @cscherrer in https://github.com/TuringLang/Bijectors.jl/issues/199#issuecomment-988028984
Handling batches/collections of inputs
The current idea is to generalize the approach taken by
RowVecs
andColVecs
from KernelFunctions.jl to handle more general storage, as discussed extensively in https://github.com/TuringLang/Bijectors.jl/discussions/178, by introducing aBatch
and then providing general implementations which performs a naivemap
or something of the sort, while simultaneously allowing implementers to specialize batch-implementations for improved efficiency when it makes sense.