8000 Support single precision in linalg, don't coerce to double · Issue #3722 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Support single precision in linalg, don't coerce to double #3722

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
charris opened this issue Sep 12, 2013 · 12 comments
Open

Support single precision in linalg, don't coerce to double #3722

charris opened this issue Sep 12, 2013 · 12 comments
Labels
17 - Task component: numpy.linalg

Comments

@charris
Copy link
Member
charris commented Sep 12, 2013

A number of single precision functions look to have come in with the gufunc work. It would be good to support them in all of the current routines.
@charris
Copy link
Member Author
charris commented Feb 23, 2014

Current status need checking.

@argriffing argriffing mentioned this issue May 21, 2015
Closed
@pv pv mentioned this issue Apr 11, 2018
Closed
@mhvk
Copy link
Contributor
8000 mhvk commented Apr 12, 2018

More true now than ever: from #10888 (which I'll close):
"""
Similar to the case for svd (#9516), lstsq currently enforces double precision. Now that we expose the single-precision BLAS functions as gufuncs (#9980), there is no longer a need for this limitation. This is a reminder that we should allow them to be used, most easily perhaps through a new dtype argument that defaults to using double precision (for discussion, see #9980).
"""

@rgommers
Copy link
Member
rgommers commented Mar 4, 2019

Just came across this one - it seems quite low prio. Given that we have conda and binary wheels for all mainstream platforms now, the rationale for the existence of lapack_lite has become a lot weaker. So I'd suggest to not put any effort in expanding lapack_lite.

@eric-wieser
Copy link
Member
eric-wieser commented Mar 4, 2019 •
edited
Loading

lapack_lite already has full single support - it's simply a port of a list of Fortran functions, and all type variants of each function should have made that list. The issue is that linalg upcasts singles to doubles.

Perhaps the tile should be adjusted.

@mhvk mhvk changed the title Support single precision in all lapack_lite routines. Support single precision in linalg, using the single precision lapack_lite versions Mar 4, 2019
@mhvk
Copy link
Contributor
mhvk commented Mar 4, 2019

Adjusted the title to refer to linalg - it would help people who deal with very large arrays.

@charris
Copy link
Member Author
charris commented Mar 4, 2019

There is another discussion related to this somewhere. AFAICT, the problem is a decision made back at the beginning that NumPy should only support double precision, leaving single precision to SciPy. That doesn't make a lot of sense to me, I think the original basis for that was that lapack-lite only supported double precision back in the beginning. If we do decide on single precision support we might want to update the ffts as well.

@mhvk
Copy link
Contributor
mhvk commented Mar 4, 2019

Agreed that we should try to be general as is possible without making a huge effort - all our ufuncs are as well! The fft may be a bit more tricky, but there I have an incentive myself...

@rgommers
Copy link
Member
rgommers commented Mar 4, 2019

NumPy should only support double precision, leaving single precision to SciPy. That doesn't make a lot of sense to me, I think the original basis for that was that lapack-lite only supported double precision back in the beginning.

That's probably a bit irrelevant right now. Thinking about what the use cases for lapack_lite are:

  1. Users on platforms without any form of binary installers that don't want to build a BLAS/LAPACK from source. used to be the dominant use case, but there's few users now; we even get conda distributions for arch/ppcle
  2. Users that need numpy but have no need for any form of linear algebra - they can save on memory by not having ATLAS/OpenBLAS/MKL/... installed.

or am I missing one?

For (2) there's no need to worry about single precision, because linalg isn't used. For (1), the intersection of the users we have there with the users that really need single precision will be very close to zero.

The fft may be a bit more tricky, but there I have an incentive myself

FFTs are a bit of a different case, because we can share the effort on PocketFFT between projects.

@mhvk
Copy link
Contributor
mhvk commented Mar 4, 2019

But @eric-wieser mentioned that lapack_lite already has full single-precision support, so the real issue is that we do not expose this at the linalg level (which means also people who have BLAS, etc., cannot use it).

@eric-wieser
Copy link
Member
eric-wieser commented Mar 4, 2019 •
edited
Loading

I think we already expose single-precision at the umath_linalg level too. It's really just the last step that's missing, primarily due to concerns of compatibility

@rgommers
Copy link
Member
rgommers commented Mar 5, 2019

Okay, that makes sense to fix then (after thinking about backwards compat). It has very little to do with lapack_lite then, I'll adjust the issue title again.

@rgommers rgommers changed the title Support single precision in linalg, using the single precision lapack_lite versions Support single precision in linalg, don't coerce to double Mar 5, 2019
@mhvk
Copy link
Contributor
mhvk commented Mar 5, 2019

OK, better title - agreed that mine had left it ambiguous whether the single precision lapack_lite needed work.

@j-bennet j-bennet mentioned this issue Feb 9, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
17 - Task component: numpy.linalg
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@charris @rgommers @eric-wieser @mhvk
0