Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

broesler
Copy link
Contributor

@broesler broesler commented Jul 7, 2025

Addresses gh-18304.

The condition number of a matrix is the product of two norms, which are
always non-negative and real-valued, so the condition number itself
should be non-negative and real-valued. This commit returns the proper
real dtype from linalg.cond, and includes tests for the condition
number of a complex matrix in various norms.

The existing docstring for linalg.cond already states that the return value is
either a float or inf, so the function behavior is now consistent with the
docstring.

Addresses numpygh-18304.

The condition number of a matrix is the product of two norms, which are
always non-negative and real-valued, so the condition number itself
should be non-negative and real-valued. This commit returns the proper
real dtype from `linalg.cond`, and includes tests for the condition
number of a complex matrix in various norms.
This commit addresses a reviewer comment on the blanket application of
`abs(r)`. It specifically ensures the return type of complex-valued
matrices will be the corresponding real type.
Copy link
Member

@seberg seberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM. I do wonder if we should add a release note, since it is a subtle fix, but it seems pretty hard to run into issues due to not getting a complex value.

@@ -2011,6 +2011,7 @@ def cond(x, p=None):
# contain nans in the entries where inversion failed.
_assert_stacked_square(x)
t, result_t = _commonType(x)
result_t = _realType(result_t) # condition number is always real
signature = 'D->D' if isComplexType(t) else 'd->d'
with errstate(all='ignore'):
invx = _umath_linalg.inv(x, signature=signature)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I think this is fine. Your other comment (deleted now) is not wrong, in that it would be fine to cast invx to the original result_t to achieve the right thing.
(Norm might in some paths end up casting back and forth then, but it would work too.)

@broesler
Copy link
Contributor Author

broesler commented Jul 8, 2025

I agree that a release note is probably not needed. There is functionally no difference, since the imaginary part was always 0 anyway. There are no member functions that differ between np.single and np.csingle (or double, respectively). I'm not sure if there are any numpy functions that would balk at getting a float vs. a complex number.

@broesler
Copy link
Contributor Author

Hi, just checking in on the status of this PR. Let me know if you need me to make any more changes before merging.

@seberg
Copy link
Member

seberg commented Jul 30, 2025

No, nothing else, just forgot. I think this is a fine solution, do you feel much about back-porting it?

Doesn't seem like a bad behavior change, so I guess we can probably just do it, but the bug was probably also around forever anyway.

@seberg seberg merged commit 19574af into numpy:main Jul 30, 2025
76 checks passed
@github-project-automation github-project-automation bot moved this from Pending authors' response to Completed in NumPy first-time contributor PRs Jul 30, 2025
@charris charris added the 09 - Backport-Candidate PRs tagged should be backported label Jul 30, 2025
charris pushed a commit to charris/numpy that referenced this pull request Aug 2, 2025
…py#29333)

* BUG: Always return a real dtype from linalg.cond.

Addresses numpygh-18304.

The condition number of a matrix is the product of two norms, which are
always non-negative and real-valued, so the condition number itself
should be non-negative and real-valued. This commit returns the proper
real dtype from `linalg.cond`, and includes tests for the condition
number of a complex matrix in various norms.

* ENH: Change type of complex results only.

This commit addresses a reviewer comment on the blanket application of
`abs(r)`. It specifically ensures the return type of complex-valued
matrices will be the corresponding real type.
@charris charris removed the 09 - Backport-Candidate PRs tagged should be backported label Aug 2, 2025
charris added a commit that referenced this pull request Aug 2, 2025
BUG: Always return a real dtype from linalg.cond (gh-18304) (#29333)
@broesler
Copy link
Contributor Author

broesler commented Aug 6, 2025

Thanks. I will backport it to the v2.x versions since v1.x is reaching end-of-life in about a month anyway.

@broesler broesler deleted the 18304-fix-linalg-cond-dtype branch August 6, 2025 13:20
broesler added a commit to broesler/numpy that referenced this pull request Aug 6, 2025
…py#29333)

* BUG: Always return a real dtype from linalg.cond.

Addresses numpygh-18304.

The condition number of a matrix is the product of two norms, which are
always non-negative and real-valued, so the condition number itself
should be non-negative and real-valued. This commit returns the proper
real dtype from `linalg.cond`, and includes tests for the condition
number of a complex matrix in various norms.

* ENH: Change type of complex results only.

This commit addresses a reviewer comment on the blanket application of
`abs(r)`. It specifically ensures the return type of complex-valued
matrices will be the corresponding real type.
broesler added a commit to broesler/numpy that referenced this pull request Aug 6, 2025
…py#29333)

* BUG: Always return a real dtype from linalg.cond.

Addresses numpygh-18304.

The condition number of a matrix is the product of two norms, which are
always non-negative and real-valued, so the condition number itself
should be non-negative and real-valued. This commit returns the proper
real dtype from `linalg.cond`, and includes tests for the condition
number of a complex matrix in various norms.

* ENH: Change type of complex results only.

This commit addresses a reviewer comment on the blanket application of
`abs(r)`. It specifically ensures the return type of complex-valued
matrices will be the corresponding real type.
broesler added a commit to broesler/numpy that referenced this pull request Aug 6, 2025
…py#29333)

* BUG: Always return a real dtype from linalg.cond.

Addresses numpygh-18304.

The condition number of a matrix is the product of two norms, which are
always non-negative and real-valued, so the condition number itself
should be non-negative and real-valued. This commit returns the proper
real dtype from `linalg.cond`, and includes tests for the condition
number of a complex matrix in various norms.

* ENH: Change type of complex results only.

This commit addresses a reviewer comment on the blanket application of
`abs(r)`. It specifically ensures the return type of complex-valued
matrices will be the corresponding real type.
@broesler broesler mentioned this pull request Aug 6, 2025
@charris
Copy link
Member

charris commented Aug 7, 2025

We only backport from main to the current release. "Support" means we post wheels on pip, possibly built with newer libraries or compiler versions, and check that they still pass the tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging this pull request may close these issues.

3 participants