general remark regarding the batch of similar PRs. I think we need to be careful to not parametrize with dtype too many tests because it doubles the time for running the tests. The test suite takes a lot of time already.

Yes -- I put a remark regarding having a mechanism to only test generally for dtype=np.float64. I think I'll create an issue for this topic.

Yes -- I put a remark regarding having a mechanism to only test generally for dtype=np.float64

I have a mechanism in mind. It comes down to a global fixture that is either triggered with a pytest mark or an ENV variable. (A custom command line option can work but it requires a little more work to make it work with --pyargs)

The ENV variable is easiest, because we can just set it in azure_pipeline.yml without additional logic. The idea looks like:

import pytest
import numpy as np
from os import environ

_SKIP32_MARK = pytest.mark.skipif(
    environ.get("SKLEARN_SKIP_FLOAT32", "1") != "0",
    reason="Set SKLEARN_SKIP_FLOAT32=0 to run float32 dtype tests",
)

# place this in `conftest.py` in scikit-learn
@pytest.fixture(params=[pytest.param(np.float32, marks=_SKIP32_MARK), np.float64])
def dtype(request):
    yield request.param

def test_dtype(dtype):
    a = np.asarray([1, 2], dtype=dtype)
    assert a.dtype == dtype

Skips float32 by default

pytest test_script.py -v

To run float32

SKLEARN_SKIP_FLOAT32=0 pytest test_script.py -v

You were faster than me, @thomasjpfan!
I like the idea of using pytest.fixtures even if it looks like an automagic trick to me.

In the meantime, I created #22680 to discuss it and to pin the group of PRs for testing on 32bit datasets.

general remark regarding the batch of similar PRs. I think we need to be careful to not parametrize with dtype too many tests because it doubles the time for running the tests. The test suite takes a lot of time already.

On top of this I think it's important to add extra assertions on what is the expected impact of fitting a model with a specific input dtype.

For instance a fitted attribute that is an array of fitted parameters could have a dtype that depends on the input, or to the contrary, we can check that the dtype of such a fitted attribute is always float64 even if the input is float32, if there is a good reason for that (e.g. to avoid a known numerical stability problem). We should add a comment in the test to explain when this is the case as in general I would expect the precision of the fitted attributes to be lower when the input data is of lower precision.

Similarly for the dtype of the arrays returned by transform for transformers, or predict for regressors or predict_proba for classifiers.

In particular assert_array_equal(a, b) and assert_allclose(a, b) can pass if a.dtype == np.float64 and b.dtype == np.float32 so it's important to explicitly check what is the expected dtype in those cases.

Similarly for the dtype of the arrays returned by transform for transformers,

For that there's the common check check_transformer_preserve_dtypes

For the attributes it's estimator and attribute specific. Some are meant to have the same dtype as the input but others are integers arrays or scalars, or whatever. For estimators that are supposed to preserve some dtypes, we usually have a dedicated test to check the dtype of the appropriate attributes.

It's however possible that we don't have tests for all of them. We should.

For that there's the common check check_transformer_preserve_dtypes

Good point. No need to duplicate this check then. We don't have anything similar for the predict method of regressors or the predict_proba method of classifier, right?

sklearn/kernel_approximation.py:                "check_transformer_preserve_dtypes": (
sklearn/manifold/tests/test_spectral_embedding.py:    `check_transformer_preserve_dtypes`. However, this test only run
sklearn/utils/estimator_checks.py:        yield check_transformer_preserve_dtypes
sklearn/utils/estimator_checks.py:def check_transformer_preserve_dtypes(name, transformer_orig):

We probably should.

We don't have anything similar for the predict method of regressors or the predict_proba method of classifier, right?

We do not. Likely deserves an issue to define what the behavior should be. For example, regressor.fit(X_32, y_64), should regressor.predict(X_32) be float32 or float64?

@thomasjpfan I created an issue: #22682

Feel free to edit. If you agree with my proposal, please remove the Needs Triage label and add a new Help Wanted label.

All the astype are missing copy=False. Looks good otherwise