Support/Adopt InverseFunctions?

[oschulz]

InverseFunctions is a lightweight central package that defines an inverse(f) API. Would be the interest in adopting/supporting it in TransformsBase?

[juliohm]

I think we considered it in the past. It seems that the transforms here don't satisfy the requirements of the InverseFunctions.jl API. Em sáb., 17 de ago. de 2024, 07:00, Oliver Schulz ***@***.***> escreveu:

…

InverseFunctions is a lightweight central package that defines an inverse(f) API. Would be the interest in adopting/supporting it in TransformsBase? — Reply to this email directly, view it on GitHub <#15>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3JZMYRYOPIDNG3KW3DZR4NL7AVCNFSM6AAAAABMVJCLISVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ3TCNBVHA3DSMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[oschulz]

Ah, thanks @juliohm !

[juliohm]

The Functional transform in TableTransforms.jl uses the InverseFunctions.jl API. Might be of your interest. Em sáb., 17 de ago. de 2024, 11:55, Oliver Schulz ***@***.***> escreveu:

…

Ah, thanks @juliohm <https://github.com/juliohm> ! — Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3JRBGG2VPOV44TRF43ZR5P7RAVCNFSM6AAAAABMVJCLISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJUHA4DEMZUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[oschulz]

Oh yes, neat! Just curious, in what way does TransformsBase.inverse not fulfill the requirement of InverseFunctions.inverse (and might we need to widen the scope in InverseFunctions for such cases)?

[juliohm]

If I recall it correctly, the docstrings mention properties such as inv(f)(f(x)) == x We support approximate equality sometimes. Don't remember other issues out of my head. Em sáb., 17 de ago. de 2024, 17:56, Oliver Schulz ***@***.***> escreveu:

…

Oh yes, neat! Just curious, in what way does TransformsBase.inverse not fulfill the requirement of InverseFunctions.inverse (and might we need to widen the scope in InverseFunctions for such cases)? — Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3IYDNTIDUIS7FOAVUDZR62GRAVCNFSM6AAAAABMVJCLISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJUHE4DGNJXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[oschulz]

Oh, approximate equality is perfectly fine for InverseFunction!

[juliohm]

@eliascarv do you remember any other issue we encountered in this context?

[eliascarv]

The InverseFunctions API is not used here because of incompatibility between the designs. The TransformsBase.isinvertible function that checks whether a transform is invertible has a fallback implemented with the transform type, while the InverseFunctions.hasinverse function that would be used in this fallback only works with instances and not with types.

[oschulz]

Thanks for the explanation @eliascarv !