Talip7/scikit-learn-issues-multilabel huggingface dataset:
BallTree.query returns inconsistent indices between scikit-learn versions 0.24.1 and 1.1.1

### Describe the bug

For the same data, `BallTree.query` can return different nearest neighbour indices if these neighbours are equally distanced from a point depending on scikit-learn version. Specifically, this can be observed in 0.24.1 vs 1.1.1.  

### Steps/Code to Reproduce

```
import numpy as np
from sklearn.neighbors import BallTree

np.random.seed(61)

X = np.random.randint(0, 3, size=(10,2))  # generated dataset

tree = BallTree(X, 4, 'hamming')
distances, indices = tree.query(X, 3, return_distance=True, dualtree=False, breadth_first=False, sort_results=True)

for i, (point, distances, indices) in enumerate(zip(X, distances, indices)):
    print(f'index {i}: datapoint {point} distances: {[round(dist,2) for dist in distances]} indices: {indices}')

```


### Expected Results

scikit-learn versions 0.24.1 and 1.1.1 would be expected to consistently show the same nearest neighbour indices whenever multiple neighbours are equally distanced from a data point

### Actual Results

scikit-learn v. 0.24.1:

<img width="549" alt="scikit-0 24 1" src="https://user-images.githubusercontent.com/21366061/174240375-d7215db5-6137-4ed6-a0d3-647d41761e19.png">

scikit-learn v. 1.1.1:

<img width="549" alt="scikit-1 1 1" src="https://user-images.githubusercontent.com/21366061/174240420-e4684662-26b1-4808-ae72-8e4ccff8e751.png">




### Versions

```shell
System:
  python: 3.9.7 (v3.9.7:1016ef3790, Aug 30 2021, 16:39:15) [Clang 6.0 (clang-600.0.57)]
executable: /Users/korigo/Downloads/scikit-0.24/bin/python3
  machine: macOS-10.16-x86_64-i386-64bit
Python dependencies:
     pip: 22.0.4
  setuptools: 62.1.0
   sklearn: 0.24.1
    numpy: 1.22.4
    scipy: 1.8.1
    Cython: None
    pandas: None
  matplotlib: None
    joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

System:
  python: 3.9.7 (v3.9.7:1016ef3790, Aug 30 2021, 16:39:15) [Clang 6.0 (clang-600.0.57)]
executable: /Users/korigo/Downloads/scikit-1.1.1/bin/python3
  machine: macOS-10.16-x86_64-i386-64bit
Python dependencies:
   sklearn: 1.1.1
     pip: 22.0.4
  setuptools: 62.1.0
    numpy: 1.22.4
    scipy: 1.8.1
    Cython: None
    pandas: None
  matplotlib: None
    joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True
```

COMMENT:
Closing this for now.

Labels: Bug, module:neighbors
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
> decide if we want to have some uniform support guarantees or not

I see no valid reason to reject large sparse matrix support for some estimators and not for others.

For instance, all estimators that support sparse high dim inputs with 10_000 dims could legitimately (attempt to) work with a large number of rows in `X_train` or `X_test` in which case they can face this problem quite quickly (e.g. with 200_000 data points).

So we could invest some effort to introduce a common test for int64 indexed sparse matrix support and use a meta-issue to track progress in supporting this consistently throughout the code base.

> decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

We could at least define a convention for the name of the typedef to be used in Cython code that manipulates such index arrays. For instance:

```python
ctypedef cnp.int32_t SPARSE_INDEX_t
```

in existing code that only support int32 indices and later upgrade this with tempita or fused types in dedicated PRs.

Labels: API, Needs Decision, cython
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
I like the idea of adopting some kind of templating for this. Considering, e.g. #16803 which I think would be much simpler using templating than fused types imo.

Edit: Actually I think it's fine as-is, templating wasn't needed there.

Labels: API, Needs Decision, cython
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
#1680 seems unrelated.

Labels: API, Needs Decision, cython
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
> #1680 seems unrelated.

Typo on my part, corrected now -- sorry 😅

Labels: API, Needs Decision, cython
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
Alright, #16803 is part of the list of linked issues.

Labels: API, Needs Decision, cython
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
For reference, [some relevant discussions on the Scientific Python Discourse regarding sparse arrays status and future directions](https://discuss.scientific-python.org/t/scientific-python-and-sparse-arrays-scipy-summary-future-directions/368).

Labels: API, Needs Decision, cython
[RFC] Support for int64 indexed SciPy sparse matrices in Cython code

At the moment we do not have systematic support for very large sparse matrices in our Cython code. That would be useful when the data is passed as a sparse matrix with more than ~2e9 columns or non-zero values.

The purpose of this issue is to link:

- reference all related issues in scikit-learn.
- decide if we want to have some uniform support guarantees or not
- decide if we need centralized Cython tooling (e.g. type declarations, tempita conventions) to add support for such matrices.

### Related issues and PRs (feel free to update this list):

For polynomial feature expansion (quite popular request):

- #16803
- #17554
- #19676 

Other models with open issues:

- #11355
- #11356
- #18090
- #18403

Other Cython estimators that could also be updated:

- neighbors models (k-NN and radius-based models) 
  - related issues not just about this problem: #23604
- k-means & variants
- Feature Hasher / Hashing Vectorizer (`sklearn/feature_extraction/_hashing_fast.pyx`)

The following PR will introduce a scikit-learn transformer that can output `int64` indexed sparse matrices (even if it's input is `int32` indexed).

- #23731 

### Helpful Python snippet

SciPy decides to use the int32 or int64 dtype depending on the dimensions of the matrix and on the number of stored non-zero elements. Here is a quick way to generate a CSR matrix that requires int64-typed `.indices` and `.indptr` attributes:

```python
>>> from scipy.sparse import csr_matrix
>>> import numpy as np
>>>
>>> X = csr_matrix(([1.0], [np.iinfo(np.int32).max + 1], [0, 1]))
>>> X
<1x2147483649 sparse matrix of type '<class 'numpy.float64'>'
        with 1 stored elements in Compressed Sparse Row format>
>>> X.indices
array([2147483648])
>>> X.indices.dtype
dtype('int64')
>>> X.indptr.dtype
dtype('int64')
```

COMMENT:
Note that #25942 intentionally reverted the `SPARSE_INDEX_t` type alias in favor of type names with explicit precision levels such as `int32_t` instead.

For estimators that have Cython code that should support `int32_t` and `int64_t` indexed inputs, we can use ad-hoc fused types or use tempita templates if Cython class attributes are needed.

Labels: API, Needs Decision, cython
Circular import of numpy error

### Describe the bug

![numpy error](https://user-images.githubusercontent.com/43936231/173898634-e2ca0b4e-a996-4d63-b63f-e2ab9113e3f3.PNG)

When i tried to run python file which import numpy, it's throwing an circular import(while i run the python file in utils folder of sklearn), while outside it's running fine.

Even during the build of the sklearn, at the end it showing a message like  Partial import of sklearn during the build process, though it's successfully installed the scikit-learn

![sklearn partial import](https://user-images.githubusercontent.com/43936231/173899618-b42e2f25-db27-48ec-a40d-781a70fa6546.PNG)
.

### Steps/Code to Reproduce

import numpy as np

### Expected Results

successfully imported


### Actual Results

ImportError: cannot import name '__version__' from partially initialized module 'numpy' (most likely due to a circular import) (F:\open_source\scikit-learn\sklearn-env\lib\site-packages\numpy\__init__.py)

### Versions

```shell
System:
    python: 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)]
executable: D:\sk\sklearn-env\Scripts\python.exe
   machine: Windows-10-10.0.19041-SP0

Python dependencies:
      sklearn: 1.2.dev0
          pip: 20.2.1
   setuptools: 49.2.1
        numpy: 1.22.4
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: None
   matplotlib: None
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: D:\sk\sklearn-env\Lib\site-packages\numpy\.libs\libopenblas.EL2C6PLE4ZYW3ECEVIV3OXXGRN2NRFM2.gfortran-win_amd64.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: D:\sk\sklearn-env\Lib\site-packages\scipy\.libs\libopenblas.XWYDX2IKJW2NMTWSFYNGFUWKQU3LYTCZ.gfortran-win_amd64.dll
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: C:\Windows\System32\vcomp140.dll
        version: None
    num_threads: 8
```

COMMENT:
This is not a problem in scikit-learn but more likely due to how you installed numpy ... I don't really know what could be causing this, if I were you I would try to recreate your virtualenv (or conda environment) from scratch and see whether the problem persists.

Please try your best to use our github issue for what seem like likely bugs in scikit-learn. I know this is often not that easy to tell ...

If you don't manage to figure it out, or can't find someone around you that can help, coming to the [office hours](https://github.com/scikit-learn/scikit-learn/issues/23070) could be one way of getting help for getting set-up and contribute to scikit-learn.

Labels: Question
Circular import of numpy error

### Describe the bug

![numpy error](https://user-images.githubusercontent.com/43936231/173898634-e2ca0b4e-a996-4d63-b63f-e2ab9113e3f3.PNG)

When i tried to run python file which import numpy, it's throwing an circular import(while i run the python file in utils folder of sklearn), while outside it's running fine.

Even during the build of the sklearn, at the end it showing a message like  Partial import of sklearn during the build process, though it's successfully installed the scikit-learn

![sklearn partial import](https://user-images.githubusercontent.com/43936231/173899618-b42e2f25-db27-48ec-a40d-781a70fa6546.PNG)
.

### Steps/Code to Reproduce

import numpy as np

### Expected Results

successfully imported


### Actual Results

ImportError: cannot import name '__version__' from partially initialized module 'numpy' (most likely due to a circular import) (F:\open_source\scikit-learn\sklearn-env\lib\site-packages\numpy\__init__.py)

### Versions

```shell
System:
    python: 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)]
executable: D:\sk\sklearn-env\Scripts\python.exe
   machine: Windows-10-10.0.19041-SP0

Python dependencies:
      sklearn: 1.2.dev0
          pip: 20.2.1
   setuptools: 49.2.1
        numpy: 1.22.4
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: None
   matplotlib: None
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: D:\sk\sklearn-env\Lib\site-packages\numpy\.libs\libopenblas.EL2C6PLE4ZYW3ECEVIV3OXXGRN2NRFM2.gfortran-win_amd64.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: D:\sk\sklearn-env\Lib\site-packages\scipy\.libs\libopenblas.XWYDX2IKJW2NMTWSFYNGFUWKQU3LYTCZ.gfortran-win_amd64.dll
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: C:\Windows\System32\vcomp140.dll
        version: None
    num_threads: 8
```

COMMENT:
Shot in the dark: do you have a file called `numpy.py` in your current directory, apparently this is one of the reason this error can happen ...
https://stackoverflow.com/questions/72069748/pandas-import-error-cannot-import-name-ndarray-from-partially-initialized-mod#comment127343249_72069748

Labels: Question