8000 MRG Feature stacker by amueller · Pull Request #1173 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]

Skip to content

MRG Feature stacker #1173

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

Merged
merged 11 commits into from
Sep 30, 2012
Merged

MRG Feature stacker #1173

merged 11 commits into from
Sep 30, 2012

Conversation

amueller
Copy link
Member

This estimator provides a Y piece for the pipeline.
I used it to combine word ngrams and char ngrams into a single transformer.
Basically it just concatenates the output of several transformers into one large feature.

If you think this is helpful, I'll add some docs and an example.
With this, together with Pipeline, one can build arbitrary complex graphs (with one source and one sink) of estimators in sklearn :)

TODO

  • tests
  • narrative documentation
  • example

Thanks to the awesome implementation of the BaseEstimator, grid search simply works - though with complicated graphs you get parameter names like feature_stacker__first_feature__feature_selection__percentile (more or less from my code ^^).

clf = RandomizedLogisticRegression(verbose=False, C=1., random_state=42,
scaling=scaling, n_resampling=50, tol=1e-3)
feature_scores_sp = clf.fit(X_sp, y).scores_
assert_equal(feature_scores, feature_scores_sp)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This hunk seems to be unrelated to this PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops sorry, forked from wrong branch. just a sec.

@ogrisel
Copy link
Member
ogrisel commented Sep 20, 2012

Very interesting. I want an example first! (then documentation and tests :)

@amueller
Copy link
Member Author

on it :)

@ogrisel
Copy link
Member
ogrisel commented Sep 20, 2012

@amueller to avoid forking from non-master branches you should use something such as http://volnitsky.com/project/git-prompt/

features.append(trans.transform(X))
issparse = [sparse.issparse(f) for f in features]
if np.any(issparse):
features = sparse.hstack(features).tocsr()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the tocsr() can be avoided. For instance the downstream model might prefer CSC such as ElasticNet for instance.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then again, bugs crop up every now and then where estimators that are supposed to handle any sparse format turn out to only handle CSR. It's a good defensive strategy to produce CSR by default (and it's unfortunate that sparse.hstack doesn't do this already).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote this thing in the heat of the battle and I don't remember if there was a reason or if it was just a precaution. I'm inclined to think that I put it there because something, somewhere, broke.

@amueller
Copy link
Member Author

Yes, it should derive from transformer mixin.
@larsmans can I interpret your comments such that you think this is a good thing to have?

@amueller
Copy link
Member Author

Added a toy example.

@ogrisel
Copy link
Member
ogrisel commented Sep 20, 2012

I think such a feature stack should provide some way to do feature group normalization in one way or another. But this probably require some experiments to know which normalization pattern is useful on such beast in practice.

Anybody has practical experience or insight to share on this?

@larsmans
Copy link
Member

GREAT idea! However, I don't like the name FeatureStacker much, as stacking implies putting things on top of each other, while this class concatenates things side-by-side.

I tried to find a "plumbing equivalent" of this class to keep with the pipeline metaphor, but I can't seem to find it. It's not quite a tee as it connects the various streams back together in the end. Maybe one of the other devs is more experienced with plumbing? :)

@ogrisel
Copy link
Member
ogrisel commented Sep 20, 2012

BTW I think the example could be improved my using a less trivial example (e.g. using the digits dataset) and showing that the cross validate score best grid searched parameter set of the pipeline with stacked features is better than the pipeline with individual feature transformers separately.

@ogrisel
Copy link
Member
ogrisel commented Sep 20, 2012

@larsmans maybe FeatureConcatenator?

@ogrisel
Copy link
Member
ogrisel commented Sep 20, 2012

FeatureUnion?

@ogrisel ogrisel closed this Sep 20, 2012
@larsmans larsmans reopened this Sep 20, 2012
@larsmans
Copy link
Member

MultiTransformer?

@amueller
Copy link
Member Author

glad you like it. the estimator and the example even more are in a v 8000 ery rough state.i wasn't sure if the was interest and i had to leave my desk without really testing the example. I'll try to polish it asap. thanks for your suggestions. i don't think this exists in plumbing btw. it's a t followed by a y. ..
Andy

Lars Buitinck notifications@github.com schrieb:

MultiTransformer?


Reply to this email directly or view it on GitHub:
#1173 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

@GaelVaroquaux
Copy link
Member

FeatureUnion?

My favorite so far

@amueller
Copy link
Member Author

I also like FeatureUnion.
Other possibilities: FeatureBinder, FeatureAssembler, FeatureCombiner.
Or maybe go away from feature? TransformerUnion, TransformBinder, TransformerBundle?

Hm i think I like TransformerBundle

@ogrisel
Copy link
Member
ogrisel commented Sep 21, 2012

+1 for FeatureAssembler or FeatureUnion or TransformerBundle

@larsmans
Copy link
Member

+1 for TransformerBundle.

@amueller
Copy link
Member Author

In my application, I found the get_feature_names very helpful - I was using text data and some handcrafted features.
I fear in general this is hard to do. I thought about doing hasattr("get_feature_names") and otherwise just return estimator_name_0, estimator_name_1,.... This might be a bit problematic, though, as I don't think there is a reliable method to get the output dimensionality of a transformer :-/

Oh and @ogrisel for the normalization, each feature should be normalized separately, right?
This is "easily" possible but feeding the object pipelines of preprocessing and transformers. As normalization might be quite application specific, I think this solution is ok for the moment.
The code doesn't actually get too messy doing this.

@amueller
Copy link
Member Author

ugh I just tried to work on the example and noticed that #1034 wasn't in master yet.
Without a good way to look at the grid search results, this PR is a lot less useful I think.
Have to work on #1034 more :-/

@larsmans
Copy link
Member

We might introduce an n_features_out_ attribute/property on all transformers that work on feature vectors. For now, only supporting get_feature_names only when all underlying transformers do would be good enough, IMHO.

@amueller
Copy link
Member Author

@larsmans ok, will do that. Should be easy enough.

@amueller
Copy link
Member Author

Having a bit of a hard time creating a good example :-/

@ogrisel
Copy link
Member
ogrisel commented Sep 21, 2012

Have you been able to use this kind of tool successfully for your kaggle contest? If so then we can stick to a simplistic toy example and tell in the narrative documentation which kind of feature bundle was proven useful in practice on which kind of problem (e.g. PCA feature + raw TF-IDF for text classification for instance).

@amueller
Copy link
< 9E88 span data-view-component="true" class="Label ml-1">Member Author

I can tell you how successful I was tomorrow ;)
It was definitely helpful to combine handcrafted features with word n-grams. Doing it using this estimator, I was still able to grid-seach for count-vectorize parameters such as min_df, ngram_range, etc. So that definitely helped.


This estimator applies a list of transformer objects in parallel to the
input data, then concatenates the results. This is useful to combine
several feature extraction mechanisms into a single estimator.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

single feature representation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer it the way it is, as getting the features out is not the important part, the important part is formulating it as an estimator.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I misunderstood what you meant. Since you're talking about extraction mechanisms, it may be clearer to say "in a single transformer".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

@mblondel
Copy link
Member

Nice idea indeed!

@amueller
Copy link
Member Author

@mblondel any votes on the name?

@mblondel
Copy link
Member

Some I like include FeatureAssembler, FeatureCombiner and FeatureUnion.

@amueller
Copy link
Member Author

Name votes:
FeatureAssembler II
FeatureCombiner I
FeatureUnion IIII
TransformerBundle III

(If I counted correctly, which is unlikely given my degree in math)
If no-one objects I'll rename to FeatureUnion and change the state of the PR to MRG.

@agramfort
Copy link
Member

+1 for FeatureUnion

I would have thought of FeatureConcat (FeatureConcatenator?) but FeatureUnion
is fine with me.

@amueller
Copy link
Member Author

Renamed, think this is good to go.

@amueller
Copy link
Member Author

Any more comments? (github claims this can not be merged but I just rebased, so it should be a fast-forward merge).

@ogrisel
Copy link
Member
ogrisel commented Sep 26, 2012

This cannot be merged in master currently but appart from that +1 for merging :)

@GaelVaroquaux
Copy link
Member

LGTM. 👍 for merge. Thanks @amueller !

@amueller amueller merged commit d087830 into scikit-learn:master Sep 30, 2012
@vene
Copy link
Member
vene commented Oct 28, 2012

Thank you for this convenient transformer. In my application I had to hack it a bit, and I wonder whether the feature I wanted could be more generally useful.

Basically, sometimes you want to concatenate the same feature extractor multiple times, and have some of the parameters tied when grid searching.

In my case, I was learning a hyphenator, so my data points consist of 2 strings: the one to the left of the current position and the one to the right of the current position. For this I defined a ProjectionVectorizer that has a column attribute that just says "I only work on X[:, column]" and concatenated two of these. Now, when grid searching, it is common sense to use the same n-gram range for both transformers, so the cleanest way to do this was this quick hack (no error handling):

class HomogeneousFeatureUnion(FeatureUnion):
    def set_params(self, **params):
        for key, value in params.iteritems():
            for _, transf in self.transformer_list:
                transf.set_params(**{key: value})

This can be easily extended to support both tied params and specific params. I'm not sure whether I overengineered this, but I still have the feeling that this might pop up in other people's applications, so I wanted to raise the question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants
0