# A more simple example:
array([[  1.,   2.],
       [  2.,  10.]])
# will be transformed in:
array([[ 0.,  0.],
       [ 1.,  1.]])

This is not a bug.
MinMaxScaler standardizes each feature (column) individually.
The docstring says:

This estimator scales and translates each feature individually such
that it is in the given range on the training set, i.e. between zero and one.

Perhaps we should consider supporting axis=None? Ping @untom.

Is there a common-enough use-case to add axis=None (I can't think of one)?

In a pinch, the same result can be had by using ravel() on the input and reshape() on the result of the scaler.

Thanks for the answers and my apologies.
axis=None would be very useful in my case.

ravel and reshape is not a pretty operation to achieve in a pipeline!

On 26 June 2015 at 02:10, Alessio Bazzica [email protected] wrote:

Thanks for the answers and my apologies.
axis=None would be very useful in my case.

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

Is this for a pairwise distance? Preprocessors apart from the KernelCenterer are not really supposed to be used on that.

Is there a reason not to support axis=None, @amueller (except in sparse
where it requires real additional work)?

On 2 July 2015 at 06:57, Andreas Mueller [email protected] wrote:

Is this for a pairwise distance? Preprocessors apart from the
KernelCenterer are not really supposed to be used on that.

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

No, I think it would actually be cool.

I can work on this, but it appears that none of the Scalers accept an "axis" argument. All of them operate only on single features independent of the other features. Should I add an "axis" argument to all of them, accepting inputs of [0, ..., ndim-1] or None (defaulting to 0)?

ndim is always 2. I thought we had an axis in the scalers but it seems that is only for the function interface. Which I feel is slightly odd.
Maybe just add 0 or None, defaulting to 0 for now. That would make sense for both MinMaxScaler and StandardScaler.

I once tried introducing an axis argument to all scalers back in #2514, but IIRC the problem was that having axis=1 does not make sense for scalers and is likely overengineering (see here: #3639 (comment) ). Since then, I have started agreeing with the viewpoint: most of sklearn assumes a Samples by Features format, and normalizing along anything else than features doesn't make much sense. For the rare cases where it is needed, there are the scaling functions.

we could add the additional axis=None to the function interface? not sure though.

Not sure how it affects the original issue in this thread (e.g. if the application scenario involves fitting a scaler on a training set and applying it on the test data or not)

I think that it's useful to allow the "axis=None" option, but that might not be the best option name. What if the Scalers took an option "grouped=False"?

@amueller I do not see a use case for axis=None. Without a use case, I am overall -1 on adding this feature.

Apart from numerical reasons, I don't see any usecase either to scaling all the features in the same way. I would be surprised if some estimators behaved differently depending on the global scale of features.

-1 as well

With the comments: #4963 (comment), #4892 (comment), #4892 (comment), I do not think we will include this feature.