Skip to content

Make set_yscale("log") consistent with semilogy() #8537

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
wants to merge 2 commits into from

Conversation

dstansby
Copy link
Member

This is an update of #8056, which fixes #8045 - I have now added the new test image, which should make the tests pass. Thanks to @jcalbert for the original fix.

emmyzero and others added 2 commits April 25, 2017 19:51
 clipping behavior as plt.semilogy(), plt.semilogx() plt.loglog()
when handing non-positive data.
@dstansby dstansby added this to the 2.0.1 (next bug fix release) milestone Apr 26, 2017
@phobson
Copy link
Member

phobson commented Apr 26, 2017

If you remove the re-generated image, does it pass? (I can't spot the differences in the github UI)

          ImageComparisonFailure: images not close (RMS 0.044):
          	result_images/test_axes/log_scales_svg.png
          	result_images/test_axes/log_scales-expected_svg.png

@dstansby
Copy link
Member Author

It seems to be the svg image (not the png one, which I updated) which is failing.

It's not failing locally on my OSX machine, and isn't failing on the OSX build either, so there must be a difference between linux and OSX when it comes to svg.

@phobson
Copy link
Member

phobson commented Apr 28, 2017

@dstansby maybe you need regenerate the SVG too.

@dstansby
Copy link
Member Author

It's not failing on my machine, so I have no way to regenerate it! I presume if a linux box regenerated it the OSX build would fail?

@QuLogic QuLogic modified the milestones: 2.0.1 (next bug fix release), 2.0.2 (next bug fix release) May 3, 2017
@dstansby
Copy link
Member Author

(note to myself to restart travis when #8672 gets merged)

@anntzer
Copy link
Contributor

anntzer commented May 27, 2017

@dstansby done for you.

@dstansby
Copy link
Member Author

dstansby commented Jun 7, 2017

Restarting travis didn't move the build to 14.04, so manually cycling the PR.

@dstansby dstansby closed this Jun 7, 2017
@dstansby dstansby reopened this Jun 7, 2017
@dstansby
Copy link
Member Author

dstansby commented Jun 8, 2017

Huh, still no luck on travis, will try and see what happens on a local linux box at some point.

@tacaswell
Copy link
Member

Can you check the history of why this was changed to clip? I have a vague memory that there was a long discussion at the time...

@dstansby
Copy link
Member Author

It was originally changed to fix #163 (comment) - changing it back will break that problem, so I adding the code in that comment as a test would be a good idea.

@tacaswell
Copy link
Member

I do not see what changed about the test image...

@efiring
Copy link
Member

efiring commented Jun 23, 2017

I think the basic idea of this--essentially reverting #2147 and thereby restoring problematic errorbar behavior (#163)--will have to be noted, and we will have to be prepared for someone to raise the issue again. Overall I think it is an improvement, though.

I think that the errorbar problem could be fixed in the errorbar code in this way: for any errorbar covering a range from negative to positive values, insert a point in the Line2D at 1e-300. It would have no effect with a linear scale, and with a log scale it would allow a line to be plotted after the negative end-point is masked out. Worth the trouble? I'm not sure.

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.0.3 (next bug fix release) Jun 25, 2017
@tacaswell
Copy link
Member

I am in favor of:

@dstansby dstansby closed this Jul 3, 2017
@dstansby dstansby deleted the fix-logclip branch July 3, 2017 20:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants