lgtm

@GaelVaroquaux Could you take a look please?

Sorry, @llllllllll, I am too tired to review this tonight. The jetlag is still killing me.

@GaelVaroquaux No worries

I'm concerned about what happens when a y is passed, but the func doesn't take/use it.

We fundamentally want this to work with np.log, np.sqrt, etc. But it looks to me like with the current implementation, we can't do CallableTransformer(np.log).transform(X, y). Wouldn't this impact the use in supervised pipelines?

This is a good point, do you think that this should accept an optional function to act on y?

I think it needs to be the same function, as it might need to use the value of y in deciding what to do to each row of X (e.g. class weights)

The very simplest solution is to just not allow this, and just ignore the y.

The next simplest solution is probably to add an attribute (uses_y=True|False), but that would make it cumbersome to grid search over callables where some use y and others don't.

I don't know what other solutions are, introspecting the callable, catching the exception? In which case maybe the call should be func(X, y=y)? This can get messy.

If we agree that a supervised pipeline with func=np.log should work by default, maybe we should have a test for this use case?

Maybe we can have it accept a tuple for the func slot, where the tuple reads: (func, pass_y) and if it is a non-tuple, just treat it like: (func, False)

After thinking about this a bit more, I think that a good thing might just be to make the call:

try:
    return func(X, y)
except TypeError:
    return func(X)

I would say that using a pass_y flag would be better; however, the search use case seems to make that not work.

Also, to address the partial vs args, kwargs, this was chosen to make searching params to the func easier.

I understand your argument. But this also adds more of a maintenance burden.

Also, it might not be that simple to do try: return func(X, y). np.log has a call signature (x[, out]) so it could actually succeed, or fail with a different exception than expected.

Simply not returning TypeError when called with two arguments cannot be unambiguously used to signal the correct signature here. Something like func(X, y=y) might be a bit better, but still, when the user runs into that one 3rd party library function that has an attribute named y by coincidence, she will have to write a clumsy lambda wrapper.

What's the most common use case here? I think it's when y isn't used at all. I also guess that grid searching over funcs that use y and that don't use y isn't that common. I'm afraid we're rushing to generalize to scenarios that nobody actually needs.

So my preferences would be, in order (and with a pretty big gap between 2 and 3):

1. simply don't support using y at all, just use X
2. have a parameter indicating whether y is expected or not, and fail accordingly if it's not passed
3. the (func, flag) tuple input
4. do heuristics to detect whether y should be used at all.

As for kwargs vs partial, I still vote for partial. Grid search would still look alright with:

grid = dict(functransformer__func=(
    partial(select_columns, cols)
    for cols in [
        (0, 1),  # sepal width & petal width
        (2, 3)  # sepal length & petal length
    ]))

And we wouldn't have to reimplement stdlib functionality.

• I prefer having a parameter for "use y". I think the case of a search that mixes callables that require or do not require y means the user needs to compensate by making all their callables behave the same way, etc.
• seeing as this is one area users are likely to use anonymous functions, their incompatibility with pickling should probably be noted in the documentation.
• partial is better than having kwargs as a constructor parameter. It ties the kwargs to the callable itself, while modifying the parameters through a kwargs param is just as cumbersome as modifying the callable itself; apart from which, I think the case where the kwargs are to be varied in a search is necessarily beyond the scope of a quick helper like this.
• perhaps the estimator should allow inverse_transform to also be provided, or we could decide that that is beyond its purpose.
• I think FunctionTransformer might be more understandable to a breadth of users.
• I'm not sure if this belongs in preprocessing; I think it is closely thematically coupled with Pipeline as a model composition utility.

+1 on what @jnothman said. inverse_transform would be great, and an argument to pass y would be, too. I don't think the "searching over func" breaks that.

I am not entirely certain about preprocessing vs pipeline module. This only really makes sense when using a pipeline, which I think is a good argument.

@llllllllll Sorry if this is taking more of your time than you anticipated.

Jumping into the conversation, as I have written myself several times such as class for personal use. However, I often find myself needing to apply a function element-wise rather than on the full X. In this setting, I dont know if proposing a shortcut for vectorizing a user-defined function would be something to consider, e.g. as a flag? (using numpy.vectorize internally, this is easy) I fear this kind of use case might pop up sooner than later once such a transformer would be shipped in scikit-learn.

Just my 2 cents -- I dont want this make this longer than it should :)

Can you give examples of element-wise functions that aren't compositions of
numpy functions?

On 4 June 2015 at 05:12, Gilles Louppe [email protected] wrote:

Jumping into the conversation, as I have written myself several times such
as class for personal use. However, I often find myself needing to apply a
function element-wise rather than on the full X. In this setting, I dont
know if proposing a shortcut for vectorizing a user-defined function would
be something to consider? (using numpy.vectorize internally, this is easy)
I fear this kind of use case might pop up sooner than later once such a
transformer would be shipped in scikit-learn.

Just my 2 cents -- I dont want this make this longer than it should :)

—
Reply to this email directly or view it on GitHub
#4798 (comment)
.

@amueller I prefer FunctionTransformer too.

Just so everyone knows, I have not forgotten about this PR; however, I have been busy with work. I will address the comments made sometime this weekend so that they can go under another round of review. Thank you all for the feedback.

Thanks @llllllllll, your contribution is much appreciated :)

I think we can keep inverses out of this PR. I'm ok with this living in sklearn.pipeline or preprocessing.

Merge conflict, please rebase or merge in master.

Merged via #5059. Thanks everybody, in particular @llllllllll for his contribution :)

As Olivier would say, 🍻

HurraH!

On 4 August 2015 at 06:13, Lars [email protected] wrote:

As Olivier would say, [image: 🍻]

—
Reply to this email directly or view it on GitHub
#4798 (comment)
.