Skip to content
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.

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

MAINT: Truncate the warning msg about ill-conditioning #7980

Merged
merged 2 commits into from
Oct 7, 2017

Conversation

ilayn
Copy link
Member

@ilayn ilayn commented Oct 5, 2017

Fixes #7951

The resulting warning message does not have the file name, which is always ../.../linalg/basic.py anyways and the line number which is also fixed. Also it doesn't have the trailing line indicator.

The current version
image

This PR

image

@ilayn
Copy link
Member Author

ilayn commented Oct 5, 2017

@rgommers Can we squeeze this into 1.0.0 or should we delay it?

@pv
Copy link
Member

pv commented Oct 5, 2017

Doesn't look right to me: monkeypatching of standard modules.

Instead of this, please add the stacklevel= argument as discussed elsewhere.

@ilayn
Copy link
Member Author

ilayn commented Oct 5, 2017

@pv Oh, I've forgotten the stacklevel arg indeed. But this is just to modify the output message. The stacklevel will only effect the trailing line (see the first image under the rcond value

@pv
Copy link
Member

pv commented Oct 5, 2017

Yes, please change the message and add the stacklevel, and remove the stuff modifying the warnings module.

I think the issue is probably not major enough to warrant a backport (ie. it's just about the precise formatting of the warning message rather than the bug).

'condition number/precision: {} / {}'.format(rcond, E),
RuntimeWarning)
'condition number{:.6e}'.format(rcond),
RuntimeWarning, stacklevel=1)
Copy link
Member

Choose a reason for hiding this comment

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

stacklevel=3 I think

Copy link
Member Author

Choose a reason for hiding this comment

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

If solve is called directly then stacklevel=3 will report -2th item on the tracestack instead of basic.py. I've highlighted the message below.

image

Copy link
Member

Choose a reason for hiding this comment

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

Yes, and that's the correct place to emit the warning.
You can also find Numpy's np.deprecate decorator emits the warning with that stacklevel.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. Just to confirm if I understand correctly, this is only going to fix for linalg.solve warning and other functions which embed linalg.solve will be left as is (which was what Eric mentioned in the linked issue).

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I agree how to best deal with the warnings situation of nested calls to e.g. solve() is an open problem, given that python's warnings module is not fully up to the task imho.

Aside from solutions that require patching the warnings module (which I think we should not start doing), setting the stacklevel at least solves the issue in simplest cases, and we can hope the non-simple cases are not that pressing...

Another thing is that the emitted warning probably should be in a separate category to make these warnings easier to filter, warnings.warn(..., category=scipy.linalg.LinAlgWarning) (with class LinAlgWarning(RuntimeWarning): ... is added to scipy.linalg).

@rgommers
Copy link
Member

rgommers commented Oct 5, 2017

I think the issue is probably not major enough to warrant a backport (ie. it's just about the precise formatting of the warning message rather than the bug).

I agree, after a release candidate we only want to backport critical bug fixes.

@ilayn
Copy link
Member Author

ilayn commented Oct 5, 2017

Ah, we don't want to change the warning message then?

I guess we can close this one instead because that's the only thing this PR does.

@@ -34,10 +40,13 @@ def _solve_check(n, info, lamch=None, rcond=None):
return
E = lamch('E')
if rcond < E:
orig_formatwarning = warnings.formatwarning
warnings.formatwarning = _truncated_warning_msg
Copy link
Member

Choose a reason for hiding this comment

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

This stuff is not ok (and not really required afaics after setting the stacklevel correctly).

Copy link
Member Author

Choose a reason for hiding this comment

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

I've picked it up from the official docs as the recommended practice to keep things local

Copy link
Member

@pv pv Oct 5, 2017

Choose a reason for hiding this comment

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

can you show where it's recommended? (some googling indicates at least one core python dev thinks otherwise)

in any case, I don't think it's required here, and moreover even if it is, it's not scipy's job to prettify the warning display

Copy link
Member Author

Choose a reason for hiding this comment

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

Here it is https://docs.python.org/3.6/library/warnings.html#warnings.formatwarning

But I get your point then we can close this PR.

'versions of SciPy.', DeprecationWarning)
warn('Use of the "debug" keyword is deprecated '
'and this keyword will be removed in future '
'versions of SciPy.', DeprecationWarning, stacklevel=3)
Copy link
Member

@pv pv Oct 6, 2017

Choose a reason for hiding this comment

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

stacklevel=2 probably

Also, ditto below

Copy link
Member Author

Choose a reason for hiding this comment

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

ah yes, forgot about _solve_check

@ilayn
Copy link
Member Author

ilayn commented Oct 6, 2017

@pv Done. Since it is an untested keyword I've skipped the CI builds.

@pv pv merged commit 6d3d70d into scipy:master Oct 7, 2017
@pv pv added this to the 1.1.0 milestone Oct 7, 2017
@ilayn ilayn deleted the solve_warning branch October 7, 2017 19:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

linalg.solve ill-condition warning
3 participants