Repository navigation
scatter + loglog = bad autolimits #5897
Description
import matplotlib.pyplot as plt
xs = [97, 4980, 9863, 14746, 19628, 24511, 29394, 34277, 39160, 44042, 48925]
ys = [7e-09, 3e-09, 1e-09, 7e-10, 4e-10, 5e-10, 2e-10, 1e-10, 1e-10, 1e-10, 1e-10]
zs = [6e-09, 3e-09, 1e-09, 7e-10, 4e-10, 2e-10, 2e-10, 1e-10, 1e-10, 1e-10, 1e-10]
plt.scatter(xs, ys)
plt.loglog(xs, zs)
plt.show()
master
1.5.1
I've also had cases where the bottom of the line plot was cut out, although I don't have a minimal example yet.
Activity
zblz commentedon Jan 30, 2016
There is indeed something fishy going on in the log scale autolimit logic. I have found a similar problem when using a
ax.set_ylim(bottom=1e-4)call: the top limit is not recomputed automatically but remains at the level of the previous view. Since the new autolimit logic, this means it might be several orders of magnitde above if the initial range before theset_ylimwas very large. MWE:On master:
On 1.4.3:
tacaswell commentedon Apr 28, 2016
This resulted in a hour long phone discussion. It seems there are significant order of operations issues here.
anntzer commentedon May 29, 2016
OK, I got it: this is because the data limits of a collection include the physical extent of the artists that are part of the collection (in this case, the markers). I guess this is necessary because artists may be quite large...
Now, when the scatterplot is made, the y extent essentially comes from the marker size + margins. In fact, it can easily be checked that changing the size of the markers will change the ylims of the final plot. Ugh.
Note that AFAICT this is different from the issue pointed out by @zblz.
zblz commentedon May 31, 2016
Yes, it looks like a different issue. @tacaswell: when you mention there is an order of operations issue did you mean with @anntzer's issue or the autolimit/zoom issue I mentioned? Maybe I should split it into a new issue...
anntzer commentedon Jun 3, 2016
@zblz: I am not sure that there is much to do about the issue you are raising. I guess the only alternative would be to store (upon a call to
margins) somewhere the information that some limits should be automatically recomputed if the "opposing" limit is moved (until overriden by a call toset_{x,y}lims). I'm not too worried about the implementation (well, perhaps a bit) but more that this may lead to all kinds of strange behavior and confused users... or perhaps not?zblz commentedon Jun 3, 2016
@anntzer: In my opinion, the current behaviour is more confusing: if a limit is set automatically to 20% beyond the data range, I expect this to hold always, even when I change the range. So I would be in favor of storing which limits are automatic and which have been manually set, and compute the auto limits on every new view given the manually set ones.
anntzer commentedon Jun 3, 2016
Fair enough.
Coming back to my own issue: I thought that at least in theory, collections could return their limits as "data-value limit + axes-value limit" (the latter coming from the e.g. rightmost artist). However things are more complicated, because which artist has its rightmost point the furthest can depend on the xlims themselves (a larger artist more to the left can "catch up" a smaller artist more to the right if the scaling is compressed enough).
NelleV commentedon Nov 11, 2016
Current master yield this results with @anntzer's code:
while @zblz
I personnally find the new results to match my expections. @anntzer Can you confirm and close if that is the case?
NelleV commentedon Nov 11, 2016
I think this was closed by #7410
anntzer commentedon Nov 11, 2016
My example still suffers from the issue described in #7413.
lzkelley commentedon Jun 25, 2018
anntzer commentedon Mar 11, 2022
Fixed by #13642, I believe.