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:
@Oddant1 thanks for the report. Could you please try to make it minimal by pinpointing a single RF fit (without RFECV) to check the amplitude of the discrepancies between platforms (e.g. on individual predictions)? Some small platform specific rounding errors can be expected as long as they are around machine precision level (e.g. 1e-7 for float32 or 1e-14 for float64 data). Furthermore, in the presence of near tied splits, random forests can learn different trees, but I don't think we can make can do anything about it (aside from implementing randomized tie-breaking as discussed in #23728, but that wouldn't fix the platform specific discrepancies).

The reproducer you give fits random data iteratively to filter out noisy variables. However, since the data is pure noise, all variables are noisy, and then it is somewhat expected that machine level rounding errors can make the whole procedure unstable and yield widely amplified discrepancies.

Labels: Bug, Needs Investigation