-
Notifications
You must be signed in to change notification settings - Fork 367
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
Support Functors as Functions in columns transformation #2984
Comments
The challenge is that we already have quite a complex system of rules how these transformations are interpreted, see:
and it is quite tricky to mess with them. I will think of what can be done here. @nalimilan - do you have any opinion here? |
I'm also hesitant in general to accept objects of any type as it can create ambiguities, but I have to admit not supporting non-
@jeremiedb "Natural" is very hard to define. Any particular reason why you wouldn't want your functors to inherit from |
Sorry for the vague wording. I had 1) in mind, that is having a type hierarchy of transformation functions such as: abstract type Projector end
struct Normalizer <: Projector
μ
σ
end
struct Quantilizer <: Projector
quantiles
end
|
Yes, but I assume that @nalimilan wants to understand why not have |
Oh I just didn't realized it could makes sense! But you're right, by doing |
For me (and I guess also @nalimilan) this is natural. Then you, through type hierarchy, signal that your object is callable. Note that this is not a unique feature of DataFrames.jl. Actually 143 methods in base Julia rely on the fact that some object is callable, e.g. to quote some common ones |
This issue relates to the transformations dispatch mechanism that doesn't recognize Functors as Functions as discussed on discourse .
I have a use case where I use Functors as pre-trained features transformations. In such context, defining those structs as sub-types of Function doesn’t seem a natural choice as a system.
Here’s a functor that applies learned normalization:
The following doesn’t work:
However, somewhat surprisingly, using ByRow does work:
So to use the vectorized form, it seems like a mapping of the Functors into Functions is required:
I can see that there’s a not too complicated way to circumvent the functor limitation through that remapping. Yet, isn’t it counterintuitive to see the Functor works in the ByRow but not in the vectorized case? Although dispatch happens differently under
ByRow
, from a user perspective,Having the opportunity to recognize Functors as Functions in the transform would be their most natural handling in my opinion.
The text was updated successfully, but these errors were encountered: