Issue 1:
Describe the bug

When the input is a Pandas DataFrame with multiple dtypes in the columns and the output is also Pandas, the dtypes aren't preserved but cast to a common type.

I believe this happens because check_array does this cast:

scikit-learn/sklearn/utils/validation.py

Line 788
in
1882672

dtype_orig = np.result_type(*dtypes_orig)

And transforms it into a NumPy array. But then when transformed back to a Pandas DataFrame, the dtypes aren't recovered:

scikit-learn/sklearn/utils/_set_output.py

Line 60
in
1882672

return pd.DataFrame(data_to_wrap, index=index, columns=columns, copy=False)

Steps/Code to Reproduce

import pandas as pd
from sklearn.feature_selection import VarianceThreshold

df = pd.DataFrame({"a": [True, False, True], "b": [1, 2, 3]})
print(df)
print(VarianceThreshold().set_output(transform="pandas").fit_transform(df))

print((df.dtypes == out.dtypes).all())

Expected Results

a b
0 True 1
1 False 2
2 True 3
a b
0 True 1
1 False 2
2 True 3
True

Actual Results

a b
0 True 1
1 False 2
2 True 3
a b
0 1 1
1 0 2
2 1 3
False

Versions

System:
python: 3.10.6 (main, Mar 10 2023, 10:55:28) [GCC 11.3.0]
executable: .../bin/python
machine: Linux-5.15.0-71-generic-x86_64-with-glibc2.35
Python dependencies:
sklearn: 1.2.2
pip: 23.1.2
setuptools: 65.5.1
numpy: 1.24.3
scipy: 1.10.1
Cython: None
pandas: 2.0.1
matplotlib: 3.7.1
joblib: 1.2.0
threadpoolctl: 3.1.0
Built with OpenMP: True
threadpoolctl info:
user_api: blas
internal_api: openblas
prefix: libopenblas
filepath: .../lib/python3.10/site-packages/numpy.libs/libopenblas64_p-r0-15028c96.3.21.so
version: 0.3.21
threading_layer: pthreads
architecture: Haswell
num_threads: 12
user_api: openmp
internal_api: openmp
prefix: libgomp
filepath: .../lib/python3.10/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
version: None
num_threads: 12
user_api: blas
internal_api: openblas
prefix: libopenblas
filepath: .../lib/python3.10/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
version: 0.3.18
threading_layer: pthreads
architecture: Haswell
num_threads: 12

Issue 2:
Scorer objects currently provide an interface that returns a scalar score given an estimator and test data. This is necessary for *SearchCV to calculate a mean score across folds, and determine the best score among parameters.

This is very hampering in terms of the diagnostic information available from a cross-fold validation or parameter exploration, which one can see by comparing to the catalogue of metrics that includes: precision and recall with F-score; scores for each of multiple classes as well as an aggregate; and error distributions (i.e. PR-curve or confusion matrix). @solomonm (#1837) and I (ML, an implementation within #1768) have independently sought Precision and Recall to be returned from cross-validation routines when F1 is used as the cross-validation objective; @eickenberg on #1381 (comment) posed a concern regarding array of scores corresponding to multiple targets.

I thought it deserved an Issue of its own to solidify the argument and its solution.

Some design options:

Allow multiple scorers to be provided to cross_val_score or *SearchCV (henceforth CVEvaluator), with one specified as the objective. But since the Scorer generally calls estimator.{predict,decision_function,predict_proba}, each scorer would repeat this work.

Separate the objective and non-objective metrics as parameters to CVEvaluator: the scoring parameter remains as it is and a diagnostics parameter provides a callable with similar (same?) arguments as Scorer, but returning a dict. This means that the prediction work is repeated but not necessarily as many times as there are metrics. This diagnostics callable is more flexible and perhaps could be passed the training data as well as the test data.

Continue to use the scoring parameter, but allow the Scorer to return a dict with a special key for the objective score. This would need to be handled by the caller. For backwards compatibility, no existing scorers would change their behaviour of returning a float. This ensures no repeated prediction work.

Add an additional method to the Scorer interface that generates a set of named outputs (as with calc_names proposed in #1837), again with a special key for the objective score. This allows users to continue using scoring='f1' but get back precision and recall for free.

Note that 3. and 4. potentially allow for any set of metrics to be composed into a scorer without redundant prediction work (and 1. allows composition with highly redundant prediction work).

Comments, critiques and suggestions are very welcome.