8000 Merge generalized linear algebra routines into numpy.linalg · Issue #3217 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Merge generalized linear algebra routines into numpy.linalg #3217

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
Closed
pv opened this issue Apr 9, 2013 · 4 comments
Closed

Merge generalized linear algebra routines into numpy.linalg #3217

pv opened this issue Apr 9, 2013 · 4 comments
Labels
17 - Task component: numpy.linalg Proposal triaged Issue/PR that was discussed in a triage meeting

Comments

@pv
Copy link
Member
pv commented Apr 9, 2013

The features in gh-2954 should be brought into numpy.linalg.

A suggested plan for action:

  1. Combine the *_lite libraries.
  2. Merge in Linear Algebra routines as generalized ufuncs #2954, without exposing the features in a public API.
  3. Change (Add generalized ufunc linalg functions and make numpy.linalg use them #3220) the implementation of routines in numpy.linalg to use umath_linalg while preserving full backward compatibility, but allow "stacked" input.
  4. Add the new routines from _gufunc_linalg.py into numpy.linalg (keep eye on Scipy function signatures, if applicable)
  5. Figure out how to deal with error handling in numpy.linalg and implement any changes.
  6. Figure out how to allow numpy.linalg routines compute single-precision in single precision (rather than using double precision LAPACK)
  7. Extend umath_linalg to cover all functions (if possible?) in numpy.linalg, and drop the old lapack_lite wrapper.

Open questions:

A. Error handling. Raising LinAlgErrors is not necessarily the right thing to do especially in the stacked case, so this should be made user controllable.
B. The numpy.linalg routines compute results for single-precision by using double precision internally. This should perhaps be made tunable?
C. Which of the generalized ufunc arguments should be exposed in the numpy.linalg API?
D. The umath_linalg error handling goes through by mis-using the invalid FP flag. Should ufunc error handling be extended here? (scipy.special would also have an use case)

Possible solutions to questions:

A. Add keyword argument raise_errors to all functions (inv, solve, eig, ...) that used to raise a LinAlgError on LAPACK errors. Perhaps also add global state, e.g. np.linalg.seterr for tuning the default value --- however, global state here may have unexpected effects in 3rd party libraries.

B. Changing the default can cause changes in results, and may make some algorithms not converge?

C. Dtype, perhaps, and maybe also axis control arguments?
This was referenced Apr 10, 2013
Merged
Closed
@pv
Copy link
Member Author
pv commented Oct 9, 2013

The unused gufuncs were removed in gh-3880. They can be added back with additional review and testing.

@pv
Copy link
Member Author
pv commented Oct 9, 2013

Steps 4, 5, 6, 7 above are not yet done. The open questions are still open.

@pv pv mentioned this issue Feb 28, 2014
Closed
This was referenced May 21, 2015
Closed
Merged
@njsmith njsmith mentioned this issue Jun 30, 2015
Open
@cmeyer cmeyer mentioned this issue Apr 27, 2016
Closed
@pv pv mentioned this issue Apr 11, 2018
Closed
@seberg seberg added component: numpy.linalg 57 - Close? Issues which may be closable unless discussion continued labels Jan 5, 2019
@mhvk
Copy link
Contributor
mhvk commented Jan 5, 2019

Let me ping @eric-wieser, who has certainly done some of these steps.

@InessaPawson InessaPawson added the triage review Issue/PR to be discussed at the next triage meeting label Dec 13, 2021
@mattip
Copy link
Member
mattip commented Feb 9, 2022

We have taken this as far as we can for now. I will close it, please open new issues/PRs for anythin that is still relevant.

@mattip mattip closed this as completed Feb 9, 2022
@InessaPawson InessaPawson added triaged Issue/PR that was discussed in a triage meeting and removed triage review Issue/PR to be discussed at the next triage meeting 57 - Close? Issues which may be closable unless discussion continued labels Mar 19, 2023
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 Proposal triaged Issue/PR that was discussed in a triage meeting
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@pv @seberg @charris @mattip @mhvk @InessaPawson
0