Repository navigation
Closed
Labels
status: confirmed bugstatus: inactiveMarked by the “Stale” Github ActionMarked by the “Stale” Github Action
Milestone
Description
Bug report
- The
markeveryoption forplot,semilogx,semilogy, andloglogplotting methods has a weird difference of behavior betweenplot / semilogyandsemilogx / loglog, when usingmarkevery = (float, float).
Code for reproduction
import numpy as np
import matplotlib.pyplot as plt
# Generate some data
X = np.linspace(-10, 10, 1000)
Y = np.sin(X)**2
# Specify markers
markers = ['o', 'v', '^', '<', '>']
def markevery(i):
# I tried a *lot* of values here, none were working for the 4 plots
return (i / 50., 0.1)
plt.figure()
# First plot in normal plot
plt.subplot(221)
for i in range(10):
plt.plot(X, Y + i / 10., marker=markers[i % len(markers)], markevery=markevery(i), label=str(i))
plt.legend()
plt.title("plt.plot(): markers are here!")
# Then plot in semilogx
plt.subplot(222)
for i in range(10):
plt.semilogx(X, Y + i / 10., marker=markers[i % len(markers)], markevery=markevery(i), label=str(i))
plt.legend()
plt.title("plt.semilogx(): markers are NOT here!")
# And then semilogy
plt.subplot(223)
for i in range(10):
plt.semilogy(X, Y + i / 10., marker=markers[i % len(markers)], markevery=markevery(i), label=str(i))
plt.legend()
plt.title("plt.semilogy(): markers are here!")
# Finally plot in loglog
plt.subplot(224)
for i in range(10):
plt.loglog(X, Y + i / 10., marker=markers[i % len(markers)], markevery=markevery(i), label=str(i))
plt.legend()
plt.title("plt.loglog(): markers are NOT here!")
plt.suptitle("Weird behavior of markevery between plt.plot, plt.semilogx, plt.semilogy, plt.loglog")
plt.show()Expected outcome
- One would expect the markers to be located in a similar fashion for each of the four plots method,
plot,semilogx,semilogy, andloglog. The two plots on the left have markers correctly located (well spacen, with a different starting point for the different curves), and the two plots on the right do not show markers. - Note that I tried a lot of different values for the
markeveryparameters (heremarkevery = (i / 50., 0.1)for the various curves, with changingito change the starting point of the markers), and always encounter this inconsistency between left and right.
Matplotlib version
- Matplotlib version 2.0.0 (
2.0.0+3337.gc15694b), with Python 3.5, on Ubuntu 16.10 - Python installed with apt, latest version of Matplotlib installed with
pip --upgrade.
Maybe I don't understand the semantic behind using markevery = (float, float), but as far as I can tell, this behavior is weird.
Thanks in advance!
Metadata
Metadata
Assignees
Labels
status: confirmed bugstatus: inactiveMarked by the “Stale” Github ActionMarked by the “Stale” Github Action

Activity
Naereen commentedon Mar 21, 2017
Can't figure this bug, see matplotlib/matplotlib#8356
phobson commentedon Mar 21, 2017
Thanks for the detailed report. What happens if you use
plotand set the x/yscales afterwards?Naereen commentedon Mar 21, 2017
Thanks for your quicky reply.
Well, it fixes the issue.
The corrected script can be:
And it gives what the first one should have given:

phobson commentedon Mar 21, 2017
OK. Thanks, that'll help us track it down.
Naereen commentedon Mar 21, 2017
Is there a way to use
set_xscaleorset_yscalewithout having to store and use the figure and then the axis object?phobson commentedon Mar 21, 2017
Yes, but I always recommend that you explicitly create and store your Figure and Axes object.
You can do e.g.,
plt.xscale('log'), but then you have keep track in your head which Axes you're operating on. Kind of a mental burden, IMHO.phobson commentedon Mar 21, 2017
For instance, I would change your code to be
alternatively, you could do:
Naereen commentedon Mar 21, 2017
Naereen commentedon Mar 22, 2017
If you feel like you need help, I will try to fix the issue myself on matplotlib's code, if someone points me to the exact and correct function/part that needs to be modified. Don't hesitate to ask me, I will try my best!
phobson commentedon Mar 22, 2017
Start digging at e.g., https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes/_axes.py#L1551
Naereen commentedon Mar 22, 2017
Seems to me that, for safety, the
self.set_xscale('log', **d)could also be done after thel = self.plot(*args, **kwargs)?Doing this (hacky) change, for semilogx,semilogy & loglog, will fix the issues.
Naereen commentedon Mar 22, 2017
In fact, I am not sure that the proper way to use
set_x/yscaleis before the call to plot.Could someone confirm?
If the semantic is not properly defined, the safer way to fix bug (but not the cleanest) is to call
set_xscalebefore and after the call toplot(...)...6 remaining items
Naereen commentedon Mar 23, 2017
OK. Clearly, I don't enough about internals of matplotlib to really understand what you explained, but I'm glad to see you seem to know what's going on.
Thanks, and good luck!
Naereen commentedon May 11, 2017
Will this be included for the 2.1 release?
phobson commentedon May 11, 2017
@Naereen we've milestoned it to be fixed by 2.1, but that's not a 100% guarantee.
Naereen commentedon Jun 19, 2017
Hi,
Any update? Any help needed?
tacaswell commentedon Jun 19, 2017
Any help working on this would be appreciated :)
Does setting
markeveryon a line object correctly recompute the locations with the current scale?Naereen commentedon Jun 22, 2017
Yes
github-actions commentedon Apr 10, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
ksunden commentedon Apr 10, 2023
This seems to have been fixed somewhere along the way, not too sure where:
QuLogic commentedon Apr 11, 2023
This was fixed by #9477 (because the
markeverycalculation produces allnanand thus plots nowhere.)