Skip to content

Default locator for log-scale messes up minor ticks sometimes #7200

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

Closed
LindyBalboa opened this issue Sep 29, 2016 · 11 comments
Closed

Default locator for log-scale messes up minor ticks sometimes #7200

LindyBalboa opened this issue Sep 29, 2016 · 11 comments
Assignees

Comments

@LindyBalboa
Copy link
Contributor

LindyBalboa commented Sep 29, 2016

Ubuntu 16.04 | Python 3.5 | MPL 2.0.0b3.post2474+gf8d05a4

Don't have time to look into this more right now. You can see it gets it right sometimes, but sometimes it is very wrong.

screenshot from 2016-09-29 11-13-57

@efiring
Copy link
Member

efiring commented Sep 29, 2016

It looks like the problem occurs when the major locator puts ticks at intervals of more than a decade. What should the minor ticks do in that case? I don't see an obvious solution, other than putting minor ticks at the decades when the major ticks are skipping decades. In the upper RHS plot in this example, the minor ticks would be at 10^-9 and 10^-7.

@efiring efiring added this to the 2.0 (style change major release) milestone Sep 29, 2016
@anntzer
Copy link
Contributor

anntzer commented Sep 29, 2016

Would it be a problem if a minor tick was always drawn at any position a major tick is drawn? (We just need to make sure that the major tick is drawn over the minor tick, if both are present.) This would also have avoided (somewhat) issues such as #6875 (comment).

@efiring
Copy link
Member

efiring commented Sep 29, 2016

That would make a mess, or more complexity to avoid the mess, in any case where minor ticks are labeled.

@anntzer
Copy link
Contributor

anntzer commented Sep 29, 2016

Good point.

@LindyBalboa
Copy link
Contributor Author

Would it be possible to decouple label generation from the ticks? There should totally still be major ticks there, but on some of my plots (ylim of 10^-17 to 10^-4) were just way too crowded and ugly. I was in a rush and just posted the first plot that showed it, so maybe not the best example.

@tacaswell
Copy link
Member

You might be able to shoe-horn some 'return an empty string' logic into LogFormatter

@NelleV
Copy link
Member

NelleV commented Nov 10, 2016

We've done a lot of work on the ticker module to improve the defaults recently, so it is possible this has been fixed. Do you mind sharing the data and the code so that I can verify we haven't fixed this already?

Thanks,
N

@NelleV NelleV self-assigned this Nov 10, 2016
@efiring
Copy link
Member

efiring commented Nov 10, 2016

Not fixed on v2.x:

import numpy as np
import matplotlib.pyplot as plt
x = np.logspace(-10, -5, 100)
plt.loglog(x, x)
plt.ylim(2.85e-14, 9.7e-3)

@NelleV NelleV modified the milestones: 2.0.1 (next bug fix release), 2.0 (style change major release) Nov 14, 2016
@QuLogic QuLogic modified the milestones: 2.0.1 (next bug fix release), 2.0.2 (next bug fix release) May 3, 2017
@tacaswell tacaswell modified the milestones: 2.1.1 (next bug fix release), 2.2 (next feature release) Oct 9, 2017
@afvincent
Copy link
Contributor

@efiring Is this still a problem with 2.1.x? Running your snippet, I get
efirings_mwe_7200_with_2 1
which looks kind of OK to me (i.e. no funny minor ticks between major y-ticks spanning over more than 1 decade). Or am I missing something?

However kind of agree with the suggestion that adding an extra unlabelled tick at each decade between the labelled tick might be a good idea.

@efiring
Copy link
Member

efiring commented Nov 17, 2017

I think we can consider the behavior sufficiently improved by #8381 that the original issue is no longer present. Therefore I will close this.

@LindyBalboa
Copy link
Contributor Author

Thanks for the continuing work guys!

@QuLogic QuLogic modified the milestones: v2.2, 2.0.2 (critical bug fixes from 2.0.1) Nov 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants