When all input elements are <= 0, min_pos returns the max float (resp. double) if input is float (resp.double). However, the max values are switched and it's actually returning the max double for float input and the max float for double input. Unlikely that it already cause an error in practice but that would have been a sneaky bug :)
I added a test that fails on main. I also added a generic test since the function was not tested at all.

I took the opportunity to fuse type the function.

I also noticed that the call to X.dtype.name is not free, whereas X.dtype is. When the inputs are rather small arrays, for instance in dict_learning they have shape ~ (n_components,), the computation can be completely dominated by the name finding:

X = np.random.RandomState(0).randn(100)                                                                                                                        

# main
%timeit min_pos(X)                                                                                                                                             
5.9 µs ± 35.5 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

# pr
%timeit min_pos(X)                                                                                                                                              
297 ns ± 2.41 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Turns out it was taking a significant proportion of the time spent in the sparse coding.