-
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
Adding support for FunctionChains.jl? #222
Comments
Sounds good! I've often hoped for a common interface for this sort of thing, especially the currently-incompatible diffeomorphism implementations that are spread across a few packages like this one. One thing I think it's important to account for is that high-dimensional transforms are themselves often implemented in terms of iteration. So we need ways to compose these iterations "vertically" and "horizontally". I've mostly worked with TransformVariables; I'm not sure how similar or different Bijectors approach might be |
I've registered FunctionChains.jl. It should, in principle, be able to replace |
I could add support for FunctionChains to Bijectors, if there's interest, e.g. via bi-directioinal conversion in a package extension? |
More a general question, not an actual objection at this point, but similar to the discussion in JuliaDiff/AbstractDifferentiation.jl#88 it's unclear to me if bi-directional conversions should be defined here or if only |
I agree, it would be nice to have a kind of convention here, to avoid "extension piracy". On the other hand, maintenance wise it would be much easier (versioning, CI, etc.) to not split and extension that "bridges" two package in respect to a specific topic, but to host the complete extension in one of them. Ideally the package maintainers would come to some agreement where to put the extensions in cases where the choice is not obvious. If the two packages is very lightweight/abstract, I think would would technically better to host the extension in the "heavy" package. That way, one can use a non-weak depencency instead of Requires on Julia <v1.9, which will improve load times there. In this specific case here, for example, FunctionChains can be very lightweight (I'll move most of it's dependencies into extensions, and Bijectors already shares pretty much all of them already anyway). So Bijectors depending on FunctionChains on Julia <= v1.8 and using and extension on >= v1.9 seems better, load-time wise, than FunctionChains using Requires on Julia <= v1.8 (since Bijectors is much heavier) and using an extension on >= v1.9. |
Shouldn't FunctionChains just "work" with Bijectors? Or am I missing something? |
I think you're right @torfjelde - I hadn't noticed that |
Exactly:) Now it should "just work" 👍 |
Thanks @torfjelde ! |
In the spirit of #199, which resulted in InverseFunctions and ChangesOfVariables: I've been looking for a lightweight package that defines composed functions that go beyondBase.ComposedFunction
, so that allow for arrays/iterators/tuples of functions, type-stable and performant. I couldn't really find anything lightweight that provides this (, though obviously the ML packages all have their own equivalent, and Bijectors hasComposed
.Update: There's FunctionChains.jl now.
(@giordano, did I overlook something?)
@willtebbutt, @devmotion, @torfjelde, @cscherrer would there be interest in creating such a common lightweight package like that? I'd volunteer to draft it.
The text was updated successfully, but these errors were encountered: