-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
[Bug]: LogLocator with subs argument fragile. #24092
Comments
Hi all, any thoughts on this? This is causing breaking behavior in a downstream application, and it'd be helpful to know whether Matplotlib maintainers think a fix will be quick, or if I should invest resources in working around this. |
I think we would accept a fix if one were forthcoming. I suspect the is in the range where we tick every two decades and that is clashing with subs. |
If you pan the "bad" example up or down you can make the ticks show up. They seem to alternate in and out based on the limits (not just the range) if you zoom out further they never appear. There is clearly something very wrong in the logic of what I'm labeling this as "good first issue" as I think the bug is clear (we should never not have tick labels!) but "hard" because the logic in the tick_values method is a bit convoluted (for a bunch of reasons, some historical, some because we are using the same code for major and minor ticks, some because people have very strong views about what log tick "should" be that are very conditional on the values involved). Any changes will have to be very careful about unintended consequences and understanding why the code was the way it was (likely will require some git/github archaeology) and adding a bunch more tests. |
Also milestoning for 3.7 as we need to fix this, but I doubt (but we should check) that this is a regression in 3.6 and expect the fix to be somewhat high-risk so we should not backport it. If I am wrong about either of those, then we can re-milestone and backport. |
In
In the case of stride > 1, ticklocs gets assigned a blank array which I believe to be the root of the problem.
The ticks appearing upon panning may be explained by Hope this helps. I would be glad to help fix this if you could guide me a little. Thanks |
I would like to tackle this. Does matplotlib assign issues or is it open for anyone to attempt to fix and submit pull requests? |
@Abitamim we do not typically assign issues (sometimes core maintainers will self-assign as a reminder to themselves) For more info see https://matplotlib.org/stable/devel/contributing.html#issues-for-new-contributors |
The test cases are based on the demonstration of the issue in upstream issue matplotlib#24092 The test case for bad plot (test_tick_values_not_empty) should fail until we implement our fix. The test case for good plot (test_tick_values_correct) should already suceed and continue to succeed after we implement our fix.
We are a group of students at KTH Royal Institute of Technology having a look at this as part of a course on software engineering. Assuming the problem is only present in the case where Reverting to the old calculation (or an equivalent one) seems to fix the problem without causing any other tests to fail. We should have a PR ready soon. |
The attempt to simplify the stride calculation in `a06f343dee3cebf035b74f65ea00b8842af448e9` seems to be the cause of the problem. Using an approach equivalent to what was there before hopefully resolves matplotlib#24092.
Yay! Thanks @II-Day-II - looking forward to this fix going live. |
The test cases are based on the demonstration of the issue in upstream issue matplotlib#24092 The test case for bad plot (test_tick_values_not_empty) should fail until we implement our fix. The test case for good plot (test_tick_values_correct) should already suceed and continue to succeed after we implement our fix.
…otlib#3) The attempt to simplify the stride calculation in `a06f343dee3cebf035b74f65ea00b8842af448e9` seems to be the cause of the problem. Using an approach equivalent to what was there before hopefully resolves matplotlib#24092.
Bug summary
Logarithmic tick markers do not appear if the y-axis scales a sufficient range, with the
subs
keyword argument ofticker.LogLocator
set to non-trivial values.Code for reproduction
Actual outcome
Expected outcome
I expect to see ticks in both cases, as appears in the "Good Plot".
Additional information
The problem is isolated to
ticker.LogLocator.tick_values()
. This returns correct values in the first case (e.g.,np.array([1.e-01 2.e-01 5.e-01 1.e+00 2.e+00 5.e+00 1.e+01 2.e+01 5.e+01 1.e+02 2.e+02 5.e+02])
), butnp.array([])
in the second case.Operating system
Windows
Matplotlib Version
3.5.2
Matplotlib Backend
module://backend_interagg
Python version
3.9.13
Jupyter version
No response
Installation
conda
The text was updated successfully, but these errors were encountered: