BUG: sqrtm dtype

Describe your issue.

sqrtm does not pass through np.float32 for single precision input. I think the behavior changed starting at 1.6.

Reporting after a debugging session (the joys of mysteriously mixing dtypes in numerical code, 😂 ).

It’s not a terrible bug or anything, but I’d like to know if this was intentional or will be changed.

I have seen this on multiple platforms now that I narrowed it down.

I really appreciate your software. Thanks!

Reproducing Code Example

Python 3.7.11 (default, Jul 27 2021, 07:03:16) 
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> import scipy.linalg as la
>>> la.sqrtm(np.zeros((10,10),dtype=np.float32)).dtype
dtype('float64')
>>>


# Old behavior:
Python 3.6.13 |Anaconda, Inc.| (default, Feb 23 2021, 12:58:59) 
[GCC Clang 10.0.0 ] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
>>> import numpy as np
>>> import scipy.linalg as la
>>> la.sqrtm(np.zeros((10,10),dtype=np.float32)).dtype
dtype(‘float32’)

Error message

See code example for differing dtype.

SciPy/NumPy/Python version information

1.6.1 1.21.2 sys.version_info(major=3, minor=7, micro=11, releaselevel=‘final’, serial=0)

[ilayn]

Ah we are busted 😃 Thanks @garrettwrong for the report. This is something we briefly discussed way back when and unfortunately went float64-only to ease up the Cythonization effort. But you are right that we need some sort of a unification. As usual I am going waaaay behind of my promises such as #12838 thus the intention is most definitely there but commitments are not in par with them. Sorry about this. I really want to get to this as soon as our work over linalg.solve materializes.

[ilayn]

Argh, I don’t think we can make it to 1.9.0 I have the PR ready but didn’t finish all the tests regarding the nd array inputs