Talip7/scikit-learn-issues-multilabel huggingface dataset:
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
If this issue is still free, I would like to try it  @MrinalTyagi

Labels: Documentation, good first issue
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
@glemaitre is this issue still open ? . if yes then i would like to contribute !

Labels: Documentation, good first issue
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
@ryuusama09 I think that @ShisuiUzumaki is working on it.
Please sync together.

Labels: Documentation, good first issue
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
@ryuusama09 feel free to take this issue since I am a bit busy.

Labels: Documentation, good first issue
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
> The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.
> 
> As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x.

alright, although can you update me with what youve done till now ?

Labels: Documentation, good first issue
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
> You can go ahead.


regarding these changes , In what file are they to be made . Actually i am a beginner and have no good idea as in what to do so if could guide me a bit ?

Labels: Documentation, good first issue
Vector Quantization Example increases rather than decreases memory use

### Describe the issue linked to the documentation

The [Vector Quantization Example](https://scikit-learn.org/stable/auto_examples/cluster/plot_face_compress.html) doesn't seem to demonstrate Vector Quantization.  

As written, the kmeans clustering approach used in the example converts a grey scale `uint8` `face` to an `int32` representation (`labels`). This increases the image memory use by 4x. 

```python
print(f'face dtype: {face.dtype}')
print(f'face bytes: {face.nbytes}')
print(f'labels dtype: {labels.dtype}')
print(f'labels bytes: {labels.nbytes}')
```
```
face dtype: uint8
face bytes: 786432
labels dtype: int32
labels bytes: 3145728
```

**Expected output**
Vector quantization output demonstrates a decrease in memory use.


**Additional details**
From [Wikipedia](https://en.wikipedia.org/wiki/Vector_quantization): "Vector quantization, also called "block quantization" or "pattern matching quantization" is often used in lossy data compression. It works by encoding values from a multidimensional vector space into a finite set of values from a discrete subspace of lower dimension. A lower-space vector requires less storage space, so the data is compressed."

I'm guessing kmeans outputs an `int32` by default.  The cluster `labels` are in the range 0,1,2,3,4. While this could be compressed to a 4 bit integer, `uint8` is as small as we can go with numpy so the example does not effectively illustrate the data compression. 

Perhaps the tutorial assumption is that the values contained in `labels` could be compressed through some other algorithm (e.g. outside of numpy). However, for someone unfamiliar with Vector Quantization, it may seem odd why someone would quantize a vector in a way that both loses information and increases memory use.

### Suggest a potential alternative/fix

1. add a comment to clarify that the quantized representation of the original face could be further compressed by another algorithm
2. replace the gray image with a color image and cast the kmeans output to a `uint8` to demonstrate the compression. Converting 3, 8 bit channels to one 8 bit channel would reduce nbytes by 67%.

COMMENT:
@ryuusama09 Please note that I have submitted a pull request for this issue, waiting for it to get reviewed.

Labels: Documentation, good first issue
NearestCentroid not handling properly distance metrics other than Manhattan or Euclidean.

### Describe the bug

Three issues, quite related.

* Using a metric that is not Manhattan or Euclidean triggers the following warning: `UserWarning: Averaging for metrics other than euclidean and manhattan not supported. The average is set to be the mean.`, but I believe an error message should be thrown instead. Indeed, computing the centroids as the average of the class samples is wrong for (I think) all distances except Euclidean, so it is misleading to actually do it even with a warning. Throwing an error here would fix the 2 following issues.

* Calling `.predict` on a `NearestCentroid` with metric `wminkowski`, `seuclidean` or `mahalanobis` throws an error, because those metrics need params that we can't pass to `NearestCentroid`. #23806 would fix the documentation, but maybe it should be nice to handle this properly in the code.

* Using any string as a `metric` (even a random string like `foobar`) does not throws an error when fitting, but does when calling `.predict`. Doing this with another classifier like `KNeighborsClassifier` throws an error at the fitting step.

If relevant I'd like to work on fixing those issues (new contributor here :)) I noticed a stalled PR (#19262) related to implementing `partial_fit` to `NearestCentroid`. Maybe I should start working on it first, as it seems to improve the code quality of `_nearest_centroid.py`, so it would be an interesting base to start with.

### Steps/Code to Reproduce

```python
#Reproduces the second issue mentionned

from sklearn.neighbors import NearestCentroid
from sklearn.datasets import load_iris
iris = load_iris()
X = iris.data
y = iris.target
nearest_centroid = NearestCentroid(metric="seuclidean")
nearest_centroid.fit(X,y)
nearest_centroid.predict(X)
```

### Expected Results

Fitting a `NearestCentroid` with a metric that is not Manhattan or Euclidean should trigger a proper error message.

### Actual Results

Error related to the second issue:
`ValueError: The 'V' parameter is required for the seuclidean metric when Y is passed.`

### Versions

```shell
System:
    python: 3.8.6 (default, Mar 29 2021, 18:42:37)  [Clang 12.0.0 (clang-1200.0.32.29)]
executable: /Users/valentinlaurent/.pyenv/versions/3.8.6/envs/lewagon/bin/python3.8
   machine: macOS-10.15.7-x86_64-i386-64bit

Python dependencies:
          pip: 22.1.1
   setuptools: 49.2.1
      sklearn: 1.0.2
        numpy: 1.19.5
        scipy: 1.6.2
       Cython: 0.29.26
       pandas: 1.1.3
   matplotlib: 3.4.1
       joblib: 1.1.0
threadpoolctl: 2.1.0

Built with OpenMP: True
```

COMMENT:
I agree with your analysis. Feel free to open a PR that throws a `ValueError` asap in fit when metric not in `["manhattan", "euclidean"]`.

This could be achieved cleanly with the help of the new parameter validation/constraints API: #23462.

Labels: Bug, module:neighbors
NearestCentroid not handling properly distance metrics other than Manhattan or Euclidean.

### Describe the bug

Three issues, quite related.

* Using a metric that is not Manhattan or Euclidean triggers the following warning: `UserWarning: Averaging for metrics other than euclidean and manhattan not supported. The average is set to be the mean.`, but I believe an error message should be thrown instead. Indeed, computing the centroids as the average of the class samples is wrong for (I think) all distances except Euclidean, so it is misleading to actually do it even with a warning. Throwing an error here would fix the 2 following issues.

* Calling `.predict` on a `NearestCentroid` with metric `wminkowski`, `seuclidean` or `mahalanobis` throws an error, because those metrics need params that we can't pass to `NearestCentroid`. #23806 would fix the documentation, but maybe it should be nice to handle this properly in the code.

* Using any string as a `metric` (even a random string like `foobar`) does not throws an error when fitting, but does when calling `.predict`. Doing this with another classifier like `KNeighborsClassifier` throws an error at the fitting step.

If relevant I'd like to work on fixing those issues (new contributor here :)) I noticed a stalled PR (#19262) related to implementing `partial_fit` to `NearestCentroid`. Maybe I should start working on it first, as it seems to improve the code quality of `_nearest_centroid.py`, so it would be an interesting base to start with.

### Steps/Code to Reproduce

```python
#Reproduces the second issue mentionned

from sklearn.neighbors import NearestCentroid
from sklearn.datasets import load_iris
iris = load_iris()
X = iris.data
y = iris.target
nearest_centroid = NearestCentroid(metric="seuclidean")
nearest_centroid.fit(X,y)
nearest_centroid.predict(X)
```

### Expected Results

Fitting a `NearestCentroid` with a metric that is not Manhattan or Euclidean should trigger a proper error message.

### Actual Results

Error related to the second issue:
`ValueError: The 'V' parameter is required for the seuclidean metric when Y is passed.`

### Versions

```shell
System:
    python: 3.8.6 (default, Mar 29 2021, 18:42:37)  [Clang 12.0.0 (clang-1200.0.32.29)]
executable: /Users/valentinlaurent/.pyenv/versions/3.8.6/envs/lewagon/bin/python3.8
   machine: macOS-10.15.7-x86_64-i386-64bit

Python dependencies:
          pip: 22.1.1
   setuptools: 49.2.1
      sklearn: 1.0.2
        numpy: 1.19.5
        scipy: 1.6.2
       Cython: 0.29.26
       pandas: 1.1.3
   matplotlib: 3.4.1
       joblib: 1.1.0
threadpoolctl: 2.1.0

Built with OpenMP: True
```

COMMENT:
Actually there is already an open PR here: #23874. It would need to be updated accordingly and the change document in the changelog (as a bugfix).

Labels: Bug, module:neighbors