Different Results on ARM and x86 when using `RFECV(RandomForestClassifier())`

### Describe the bug

When using  `RFECV(RandomForestClassifier())` with `sklearn=1.7.1` with `numpy>=2.0.0`, I am seeing significant discrepancies in floating point results between ARM Macs and x86 Macs/Linux machines. This discrepancy goes away when I downgrade to `numpy=1.26.4`

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd

from sklearn.ensemble import RandomForestClassifier
from sklearn.feature_selection import RFECV


def _extract_rfe_scores(rfecv):
    grid_scores_ = rfecv.cv_results_['mean_test_score']
    n_features = len(rfecv.ranking_)
    # If using fractional step, step = integer of fraction * n_features
    if rfecv.step < 1:
        rfecv.step = int(rfecv.step * n_features)
    # Need to manually calculate x-axis, grid_scores_ is a 1-d array
    x = [n_features - (n * rfecv.step)
         for n in range(len(grid_scores_)-1, -1, -1)]
    if x[0] < 1:
        x[0] = 1
    return pd.Series(grid_scores_, index=x, name='Accuracy')

np.random.seed(0)
X = np.random.rand(50, 20)
y = np.random.randint(0, 2, 50)

exp = pd.Series([
            0.4999999999999999, 0.52, 0.52, 0.5399999999999999,
            0.44000000000000006, 0.52, 0.4600000000000001,
            0.5599999999999998, 0.52, 0.52, 0.5, 0.5399999999999999, 0.54,
            0.5599999999999999, 0.47999999999999987, 0.6199999999999999,
            0.5399999999999999, 0.5, 0.4999999999999999, 0.45999999999999996],
            index=pd.Index(range(1, 21)), name='Accuracy')

selector = RFECV(RandomForestClassifier(
    random_state=123, n_estimators=2), step=1, cv=10)
selector = selector.fit(X, y.ravel())
selector_series = _extract_rfe_scores(selector)

pd.testing.assert_series_equal(selector_series, exp)
```

### Expected Results

I expect the resulting `selector_series` to be equal to `exp` or

```
 [0.4999999999999999, 0.52, 0.52, 0.5399999999999999,
  0.44000000000000006, 0.52, 0.4600000000000001,
  0.5599999999999998, 0.52, 0.52, 0.5, 0.5399999999999999, 0.54,
  0.5599999999999999, 0.47999999999999987, 0.6199999999999999,
  0.5399999999999999, 0.5, 0.4999999999999999, 0.45999999999999996]
```

across all architectures as was the case previously.


### Actual Results

I am seeing the expected result when using ARM Macs; however, when using x86 Macs or Linux I am seeing the following significantly different series.

```
 [0.5, 0.5, 0.4800000000000001, 0.6199999999999999,
  0.6000000000000001, 0.62, 0.56,
  0.5, 0.54, 0.45999999999999996, 0.44000000000000006, 0.6399999999999999, 0.52, 
  0.45999999999999996, 0.47999999999999987, 0.6, 
  0.5599999999999999, 0.5, 0.47999999999999987, 0.45999999999999996]
```

### Versions

```shell
System:
    python: 3.12.3 | packaged by conda-forge | (main, Apr 15 2024, 18:38:13) [GCC 12.3.0]
executable: /home/anthony/miniconda3/envs/test/bin/python
   machine: Linux-6.8.0-78-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.7.1
          pip: 25.1
   setuptools: 78.1.1
        numpy: 2.2.6
        scipy: 1.16.1
       Cython: None
       pandas: 2.3.1
   matplotlib: None
       joblib: 1.5.1
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /home/anthony/miniconda3/envs/test/lib/libomp.so
        version: None
```

COMMENT:
It's possible that numpy 2 has made changes that introduced discrepancies in platform specific rounding errors. However, code and tests should ideally not be dependent on machine level precisions rounding errors.

For the reproducer above, we have discrete/hard decisions (which feature to select first) that depend on noisy rankings (derived non-informative features) which are expected to be impacted by rounding errors. The fact that we did not observe platform-specific handling of those in the past should not be a justification for those not to happen in the future.

I would therefore recommend rewriting this test in a way that ensures that the order of selected features depends on statistical properties of the data that are several orders of magnitude larger than machine precision level.

Let me close this issue but feel free to open a new one if you can isolate a case where this is the case.

Labels: Bug, Needs Investigation