Talip7/scikit-learn-issues-multilabel huggingface dataset:
LASSO Solve badly when alpha is extremely small

### Describe the bug

There are 2 problem:

- when `tol=1e-4`(default), the solver does not give a warning when it solved badly.
- when `alpha` is extrimely small (like 1e-8), the solver could not find solution properly.

### Steps/Code to Reproduce

In this case, solver even do not raise a warning until `tol` = 1e-5.
```python
from sklearn.linear_model import MultiTaskLasso
import numpy as np

seed = 114514
np.random.seed(seed)

m = 256
n = 512
l = 2
k = int(m*0.1)

X = np.random.randn(m, n)
u = np.zeros((n, l))
# randomly choose k rows of u
u[np.random.choice(n, k, replace=False), :] = np.random.randn(k, l)
y = np.dot(X, u)

def loss(w:np.ndarray):
    return 0.5/m * np.linalg.norm(y - np.dot(X, w), ord='fro')**2 + 0.01 * np.linalg.norm(w, ord=1, axis=0).sum()

def err_to_exact(w:np.ndarray):
    return np.linalg.norm(w - u, ord='fro')

def err_fn(w1:np.ndarray,w2:np.ndarray):
    return np.linalg.norm(w1 - w2, ord='fro')

clf = MultiTaskLasso(alpha=0.01/m)
# clf = MultiTaskLasso(alpha=0.01/m,tol=1e-5)
clf.fit(X, y)
x = clf.coef_.T
print("dual gap:",clf.dual_gap_)
print("origin u loss:",loss(u))
print("iter:{}, loss:{}, err-to-exact:{}".format(clf.n_iter_,loss(x),err_to_exact(x)))
```


### Expected Results

To solve the problem when `tol` is quite small, we should do warm up training and train the model from larger $\alpha$ to smaller.
temp solution:
```python
clf = MultiTaskLasso(alpha=1/m,tol=1e-5,warm_start=True)
for i in range(3):
    clf.fit(X,y)
    clf.alpha /= 10
```
output:
```
dual gap: 6.679412639977893e-05
origin u loss: 0.5091769015638326
iter:6, loss:0.5091640128686069, err-to-exact:0.00021114026824291122
```
should we add it into .fit method?

### Actual Results

when $tol=1e-4,\alpha=0.01/m$:
```
dual gap: 0.0060915764336923126
origin u loss: 0.5091769015638326
iter:20, loss:2.2204027219101863, err-to-exact:9.758212052573763
```
The loss is quite larger than the origin u, so it must be wrong.
when $tol=1e-5,\alpha=0.01/m$:
```
Warning: Objective did not converge. You might want to increase the number of iterations. 
Duality gap: 1.3354989080418382, tolerance: 0.22307386842917606
  ) = cd_fast.enet_coordinate_descent_multi_task(
dual gap: 0.005216792609538431
origin u loss: 0.5091769015638326
iter:1000, loss:1.9859143908713657, err-to-exact:9.067098629992879
```

### Versions

```shell
1.2.2
```

COMMENT:
This is not a bug, i.e. the warning is correct. If you increase max_iter a lot, you will get the correct result - even if quite inefficient.

I suggest to document this, maybe even give a hint in the ConvergenceWarning. I don't think we should implement the warm-start solution because it is unclear when to start with this strategy.

@agramfort @TomDLT Do you have other suggestions here?

Labels: Bug, help wanted
LASSO Solve badly when alpha is extremely small

### Describe the bug

There are 2 problem:

- when `tol=1e-4`(default), the solver does not give a warning when it solved badly.
- when `alpha` is extrimely small (like 1e-8), the solver could not find solution properly.

### Steps/Code to Reproduce

In this case, solver even do not raise a warning until `tol` = 1e-5.
```python
from sklearn.linear_model import MultiTaskLasso
import numpy as np

seed = 114514
np.random.seed(seed)

m = 256
n = 512
l = 2
k = int(m*0.1)

X = np.random.randn(m, n)
u = np.zeros((n, l))
# randomly choose k rows of u
u[np.random.choice(n, k, replace=False), :] = np.random.randn(k, l)
y = np.dot(X, u)

def loss(w:np.ndarray):
    return 0.5/m * np.linalg.norm(y - np.dot(X, w), ord='fro')**2 + 0.01 * np.linalg.norm(w, ord=1, axis=0).sum()

def err_to_exact(w:np.ndarray):
    return np.linalg.norm(w - u, ord='fro')

def err_fn(w1:np.ndarray,w2:np.ndarray):
    return np.linalg.norm(w1 - w2, ord='fro')

clf = MultiTaskLasso(alpha=0.01/m)
# clf = MultiTaskLasso(alpha=0.01/m,tol=1e-5)
clf.fit(X, y)
x = clf.coef_.T
print("dual gap:",clf.dual_gap_)
print("origin u loss:",loss(u))
print("iter:{}, loss:{}, err-to-exact:{}".format(clf.n_iter_,loss(x),err_to_exact(x)))
```


### Expected Results

To solve the problem when `tol` is quite small, we should do warm up training and train the model from larger $\alpha$ to smaller.
temp solution:
```python
clf = MultiTaskLasso(alpha=1/m,tol=1e-5,warm_start=True)
for i in range(3):
    clf.fit(X,y)
    clf.alpha /= 10
```
output:
```
dual gap: 6.679412639977893e-05
origin u loss: 0.5091769015638326
iter:6, loss:0.5091640128686069, err-to-exact:0.00021114026824291122
```
should we add it into .fit method?

### Actual Results

when $tol=1e-4,\alpha=0.01/m$:
```
dual gap: 0.0060915764336923126
origin u loss: 0.5091769015638326
iter:20, loss:2.2204027219101863, err-to-exact:9.758212052573763
```
The loss is quite larger than the origin u, so it must be wrong.
when $tol=1e-5,\alpha=0.01/m$:
```
Warning: Objective did not converge. You might want to increase the number of iterations. 
Duality gap: 1.3354989080418382, tolerance: 0.22307386842917606
  ) = cd_fast.enet_coordinate_descent_multi_task(
dual gap: 0.005216792609538431
origin u loss: 0.5091769015638326
iter:1000, loss:1.9859143908713657, err-to-exact:9.067098629992879
```

### Versions

```shell
1.2.2
```

COMMENT:
I am confused what you call exact here? You should not expect to find the simulated coefs with more features than samples and in any case with alpha > 0. What you can expect is to find the correct support but definitely not the perfect amplitudes for the coefs. Note the in sklearn the default parameters are set with prediction performance in mind so here it's unclear if using a tol less than 1e-4 is necessary for a good cross-validation score.

Labels: Bug, help wanted
LASSO Solve badly when alpha is extremely small

### Describe the bug

There are 2 problem:

- when `tol=1e-4`(default), the solver does not give a warning when it solved badly.
- when `alpha` is extrimely small (like 1e-8), the solver could not find solution properly.

### Steps/Code to Reproduce

In this case, solver even do not raise a warning until `tol` = 1e-5.
```python
from sklearn.linear_model import MultiTaskLasso
import numpy as np

seed = 114514
np.random.seed(seed)

m = 256
n = 512
l = 2
k = int(m*0.1)

X = np.random.randn(m, n)
u = np.zeros((n, l))
# randomly choose k rows of u
u[np.random.choice(n, k, replace=False), :] = np.random.randn(k, l)
y = np.dot(X, u)

def loss(w:np.ndarray):
    return 0.5/m * np.linalg.norm(y - np.dot(X, w), ord='fro')**2 + 0.01 * np.linalg.norm(w, ord=1, axis=0).sum()

def err_to_exact(w:np.ndarray):
    return np.linalg.norm(w - u, ord='fro')

def err_fn(w1:np.ndarray,w2:np.ndarray):
    return np.linalg.norm(w1 - w2, ord='fro')

clf = MultiTaskLasso(alpha=0.01/m)
# clf = MultiTaskLasso(alpha=0.01/m,tol=1e-5)
clf.fit(X, y)
x = clf.coef_.T
print("dual gap:",clf.dual_gap_)
print("origin u loss:",loss(u))
print("iter:{}, loss:{}, err-to-exact:{}".format(clf.n_iter_,loss(x),err_to_exact(x)))
```


### Expected Results

To solve the problem when `tol` is quite small, we should do warm up training and train the model from larger $\alpha$ to smaller.
temp solution:
```python
clf = MultiTaskLasso(alpha=1/m,tol=1e-5,warm_start=True)
for i in range(3):
    clf.fit(X,y)
    clf.alpha /= 10
```
output:
```
dual gap: 6.679412639977893e-05
origin u loss: 0.5091769015638326
iter:6, loss:0.5091640128686069, err-to-exact:0.00021114026824291122
```
should we add it into .fit method?

### Actual Results

when $tol=1e-4,\alpha=0.01/m$:
```
dual gap: 0.0060915764336923126
origin u loss: 0.5091769015638326
iter:20, loss:2.2204027219101863, err-to-exact:9.758212052573763
```
The loss is quite larger than the origin u, so it must be wrong.
when $tol=1e-5,\alpha=0.01/m$:
```
Warning: Objective did not converge. You might want to increase the number of iterations. 
Duality gap: 1.3354989080418382, tolerance: 0.22307386842917606
  ) = cd_fast.enet_coordinate_descent_multi_task(
dual gap: 0.005216792609538431
origin u loss: 0.5091769015638326
iter:1000, loss:1.9859143908713657, err-to-exact:9.067098629992879
```

### Versions

```shell
1.2.2
```

COMMENT:
No further activity nor action required. Closing.

Labels: Bug, help wanted
`classification_report` gives micro averages when `labels` is a superset of the observed labels

### Describe the bug

When the value of the `labels` parameter is a superset of all observed classes in `y_true` and `y_pred`, `classification_report()` gives separate macro average values for precision, recall, and F1, although according to [the documentation](https://scikit-learn.org/1.3/modules/generated/sklearn.metrics.classification_report.html) this should only be done when `labels` is a subset of the observed classes.

### Steps/Code to Reproduce

```python
from sklearn.metrics import classification_report
print(classification_report([0, 1], [1, 0], labels=[0, 1, 2], zero_division=0.0))
```

### Expected Results

```
              precision    recall  f1-score   support

           0       0.00      0.00      0.00       1.0
           1       0.00      0.00      0.00       1.0
           2       0.00      0.00      0.00       0.0

    accuracy                           0.00       2.0
   macro avg       0.00      0.00      0.00       2.0
weighted avg       0.00      0.00      0.00       2.0
```

### Actual Results

```
              precision    recall  f1-score   support

           0       0.00      0.00      0.00       1.0
           1       0.00      0.00      0.00       1.0
           2       0.00      0.00      0.00       0.0

   micro avg       0.00      0.00      0.00       2.0
   macro avg       0.00      0.00      0.00       2.0
weighted avg       0.00      0.00      0.00       2.0
```

### Versions

```shell
System:
    python: 3.11.5 (main, Sep 11 2023, 13:54:46) [GCC 11.2.0]
executable: /home/connor/miniconda3/envs/playground/bin/python
   machine: Linux-6.2.0-37-generic-x86_64-with-glibc2.35

Python dependencies:
      sklearn: 1.3.2
          pip: 23.3
   setuptools: 68.0.0
        numpy: 1.26.2
        scipy: 1.11.4
       Cython: None
       pandas: None
   matplotlib: None
       joblib: 1.3.2
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libgomp
       filepath: /home/connor/miniconda3/envs/playground/lib/python3.11/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None

       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/connor/miniconda3/envs/playground/lib/python3.11/site-packages/numpy.libs/libopenblas64_p-r0-0cf96a72.3.23.dev.so
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: Zen

       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/connor/miniconda3/envs/playground/lib/python3.11/site-packages/scipy.libs/libopenblasp-r0-23e5df77.3.21.dev.so
        version: 0.3.21.dev
threading_layer: pthreads
   architecture: Zen
```

COMMENT:
Is anyone working on this? I am taking this up otherwise. Thanks!

Labels: Bug
`classification_report` gives micro averages when `labels` is a superset of the observed labels

### Describe the bug

When the value of the `labels` parameter is a superset of all observed classes in `y_true` and `y_pred`, `classification_report()` gives separate macro average values for precision, recall, and F1, although according to [the documentation](https://scikit-learn.org/1.3/modules/generated/sklearn.metrics.classification_report.html) this should only be done when `labels` is a subset of the observed classes.

### Steps/Code to Reproduce

```python
from sklearn.metrics import classification_report
print(classification_report([0, 1], [1, 0], labels=[0, 1, 2], zero_division=0.0))
```

### Expected Results

```
              precision    recall  f1-score   support

           0       0.00      0.00      0.00       1.0
           1       0.00      0.00      0.00       1.0
           2       0.00      0.00      0.00       0.0

    accuracy                           0.00       2.0
   macro avg       0.00      0.00      0.00       2.0
weighted avg       0.00      0.00      0.00       2.0
```

### Actual Results

```
              precision    recall  f1-score   support

           0       0.00      0.00      0.00       1.0
           1       0.00      0.00      0.00       1.0
           2       0.00      0.00      0.00       0.0

   micro avg       0.00      0.00      0.00       2.0
   macro avg       0.00      0.00      0.00       2.0
weighted avg       0.00      0.00      0.00       2.0
```

### Versions

```shell
System:
    python: 3.11.5 (main, Sep 11 2023, 13:54:46) [GCC 11.2.0]
executable: /home/connor/miniconda3/envs/playground/bin/python
   machine: Linux-6.2.0-37-generic-x86_64-with-glibc2.35

Python dependencies:
      sklearn: 1.3.2
          pip: 23.3
   setuptools: 68.0.0
        numpy: 1.26.2
        scipy: 1.11.4
       Cython: None
       pandas: None
   matplotlib: None
       joblib: 1.3.2
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libgomp
       filepath: /home/connor/miniconda3/envs/playground/lib/python3.11/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None

       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/connor/miniconda3/envs/playground/lib/python3.11/site-packages/numpy.libs/libopenblas64_p-r0-0cf96a72.3.23.dev.so
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: Zen

       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/connor/miniconda3/envs/playground/lib/python3.11/site-packages/scipy.libs/libopenblasp-r0-23e5df77.3.21.dev.so
        version: 0.3.21.dev
threading_layer: pthreads
   architecture: Zen
```

COMMENT:
Fixed by #28399

Labels: Bug
Dummy estimators don't have the `feature_names_in_` nor `n_features_in_` attributes

### Describe the bug

`DummyClassifier` and `DummyRegressor` estimators don't have the `feature_names_in_` nor `n_features_in_` attributes. The reason is that they don't call `self._validate_data` during `fit` like other estimators do.

### Steps/Code to Reproduce

```python
from sklearn.datasets import load_breast_cancer
from sklearn.dummy import DummyClassifier

X, y = load_breast_cancer(return_X_y=True, as_frame=True)

dummy = DummyClassifier().fit(X, y)
print(dummy.feature_names_in_)  # Fails
```

### Expected Results

No errors.

### Actual Results

```
Traceback (most recent call last):
  File "C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\IPython\core\interactiveshell.py", line 3548, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-3-bf0e7a849755>", line 7, in <module>
    print(dummy.feature_names_in_)  # Fails
          ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'DummyClassifier' object has no attribute 'feature_names_in_'
```

### Versions

```shell
System:
    python: 3.11.2 (tags/v3.11.2:878ead1, Feb  7 2023, 16:38:35) [MSC v.1934 64 bit (AMD64)]
executable: C:\Users\Mavs\Documents\Python\ATOM\venv311\Scripts\python.exe
   machine: Windows-10-10.0.19045-SP0
Python dependencies:
      sklearn: 1.3.2
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.24.4
        scipy: 1.11.3
       Cython: 3.0.5
       pandas: 2.1.2
   matplotlib: 3.8.0
       joblib: 1.3.2
threadpoolctl: 3.2.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libopenblas
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\numpy\.libs\libopenblas64__v0.3.21-gcc_10_3_0.dll
        version: 0.3.21
threading_layer: pthreads
   architecture: Zen
       user_api: openmp
   internal_api: openmp
    num_threads: 16
         prefix: vcomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libopenblas
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\scipy.libs\libopenblas_v0.3.20-571-g3dec11c6-gcc_10_3_0-c2315440d6b6cef5037bad648efc8c59.dll
        version: 0.3.21.dev
threading_layer: pthreads
   architecture: Zen
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libiomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\torch\lib\libiomp5md.dll
        version: None
       user_api: openmp
   internal_api: openmp
    num_threads: 1
         prefix: libiomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\torch\lib\libiompstubs5md.dll
        version: None
```

COMMENT:
probably it's more a feature request than a bug. I am willing to make a PR for this.

Labels: Bug
Dummy estimators don't have the `feature_names_in_` nor `n_features_in_` attributes

### Describe the bug

`DummyClassifier` and `DummyRegressor` estimators don't have the `feature_names_in_` nor `n_features_in_` attributes. The reason is that they don't call `self._validate_data` during `fit` like other estimators do.

### Steps/Code to Reproduce

```python
from sklearn.datasets import load_breast_cancer
from sklearn.dummy import DummyClassifier

X, y = load_breast_cancer(return_X_y=True, as_frame=True)

dummy = DummyClassifier().fit(X, y)
print(dummy.feature_names_in_)  # Fails
```

### Expected Results

No errors.

### Actual Results

```
Traceback (most recent call last):
  File "C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\IPython\core\interactiveshell.py", line 3548, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-3-bf0e7a849755>", line 7, in <module>
    print(dummy.feature_names_in_)  # Fails
          ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'DummyClassifier' object has no attribute 'feature_names_in_'
```

### Versions

```shell
System:
    python: 3.11.2 (tags/v3.11.2:878ead1, Feb  7 2023, 16:38:35) [MSC v.1934 64 bit (AMD64)]
executable: C:\Users\Mavs\Documents\Python\ATOM\venv311\Scripts\python.exe
   machine: Windows-10-10.0.19045-SP0
Python dependencies:
      sklearn: 1.3.2
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.24.4
        scipy: 1.11.3
       Cython: 3.0.5
       pandas: 2.1.2
   matplotlib: 3.8.0
       joblib: 1.3.2
threadpoolctl: 3.2.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libopenblas
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\numpy\.libs\libopenblas64__v0.3.21-gcc_10_3_0.dll
        version: 0.3.21
threading_layer: pthreads
   architecture: Zen
       user_api: openmp
   internal_api: openmp
    num_threads: 16
         prefix: vcomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libopenblas
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\scipy.libs\libopenblas_v0.3.20-571-g3dec11c6-gcc_10_3_0-c2315440d6b6cef5037bad648efc8c59.dll
        version: 0.3.21.dev
threading_layer: pthreads
   architecture: Zen
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libiomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\torch\lib\libiomp5md.dll
        version: None
       user_api: openmp
   internal_api: openmp
    num_threads: 1
         prefix: libiomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\torch\lib\libiompstubs5md.dll
        version: None
```

COMMENT:
these estimators are not really checking the input `X` and hence they don't store feature names. I'm not sure if it's a good idea to add that validation step.

Labels: Bug
Dummy estimators don't have the `feature_names_in_` nor `n_features_in_` attributes

### Describe the bug

`DummyClassifier` and `DummyRegressor` estimators don't have the `feature_names_in_` nor `n_features_in_` attributes. The reason is that they don't call `self._validate_data` during `fit` like other estimators do.

### Steps/Code to Reproduce

```python
from sklearn.datasets import load_breast_cancer
from sklearn.dummy import DummyClassifier

X, y = load_breast_cancer(return_X_y=True, as_frame=True)

dummy = DummyClassifier().fit(X, y)
print(dummy.feature_names_in_)  # Fails
```

### Expected Results

No errors.

### Actual Results

```
Traceback (most recent call last):
  File "C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\IPython\core\interactiveshell.py", line 3548, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-3-bf0e7a849755>", line 7, in <module>
    print(dummy.feature_names_in_)  # Fails
          ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'DummyClassifier' object has no attribute 'feature_names_in_'
```

### Versions

```shell
System:
    python: 3.11.2 (tags/v3.11.2:878ead1, Feb  7 2023, 16:38:35) [MSC v.1934 64 bit (AMD64)]
executable: C:\Users\Mavs\Documents\Python\ATOM\venv311\Scripts\python.exe
   machine: Windows-10-10.0.19045-SP0
Python dependencies:
      sklearn: 1.3.2
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.24.4
        scipy: 1.11.3
       Cython: 3.0.5
       pandas: 2.1.2
   matplotlib: 3.8.0
       joblib: 1.3.2
threadpoolctl: 3.2.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libopenblas
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\numpy\.libs\libopenblas64__v0.3.21-gcc_10_3_0.dll
        version: 0.3.21
threading_layer: pthreads
   architecture: Zen
       user_api: openmp
   internal_api: openmp
    num_threads: 16
         prefix: vcomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libopenblas
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\scipy.libs\libopenblas_v0.3.20-571-g3dec11c6-gcc_10_3_0-c2315440d6b6cef5037bad648efc8c59.dll
        version: 0.3.21.dev
threading_layer: pthreads
   architecture: Zen
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libiomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\torch\lib\libiomp5md.dll
        version: None
       user_api: openmp
   internal_api: openmp
    num_threads: 1
         prefix: libiomp
       filepath: C:\Users\Mavs\Documents\Python\ATOM\venv311\Lib\site-packages\torch\lib\libiompstubs5md.dll
        version: None
```

COMMENT:
It makes sense to not do the validation, but they could still store feature names, just for continuity of the API.

Labels: Bug