Skip to content

Semilog plots with zero values #3998

Closed
Closed

Description

@raoulbq

Consider the following test code:

from numpy import *
from matplotlib.pyplot import *


x = arange(-10,10)
y = (1.0 - 1.0/(x**2+1))**20

figure()
semilogy(x, y, "-o")
grid(True)
savefig("test.png")

Correct Plot (the value y=0 at x=0 is masked out from y-log plot):
test_good

Wrong Plot (spurious point at x=0 with y=1e-1):
test_wrong

A git bisect tells me that:

91725d8665975de9a26d631445ab1448b0391e1a is the first bad commit
commit 91725d8665975de9a26d631445ab1448b0391e1a
Author: Joel B. Mohler <joel@kiwistrawberry.us>
Date:   Thu Aug 21 10:43:28 2014 -0400

    use _fast_from_codes_and_verts in transform code

The commit diff introduces the use of _fast_from_codes_and_verts,
so the issue is probably somewhere deeper inside this function.

Activity

  1. added this to the v1.4.3 milestone on Jan 13, 2015
  2. tacaswell commented on Jan 13, 2015

    @tacaswell
    Member
  3. modified the milestones: v1.4.x, v1.4.3, on Jan 17, 2015
  4. tacaswell commented on Jan 17, 2015

    @tacaswell
    Member

    Retagged this as 1.5.x as this commit is not on the 1.4.x branch phew.

  5. jbmohler commented on Jan 17, 2015

    @jbmohler
    Contributor

    Good, I'm also glad to see this is not on the 1.4.x branch. I looked at this a bit, but it's not obvious to me how the optimized constructor is in-equivalent from the normal Path init relevant to this bug. My general comment is that looking at this reminded me how expensive the transform code is in the drawing. In fact, it appears that the transform is run separately/redundantly for the vertices and the path. It seems there are two performance issues -- this transform could be cached for later screen updates (e.g. resizing the window doesn't require recomputing the log transform) and the redundancy alleged in this paragraph.

    It may make sense to revert the change and look at the transform code altogether. Certainly that's a daunting prospect.

    Perhaps here is as good as any place to make my next mildly outrageous claim. There's a 4-fold (or more) rendering speed improvement for interactive applications (e.g. qtagg backend) to be had by doing the following 3 things:

    These things are in order of speed gain so it's difficult for me to get enthusiastic about attacking transform code.

  6. tacaswell commented on Jan 17, 2015

    @tacaswell
    Member

    @jbmohler I have also been looking at it and am also not seeing what is different. Can you send an email to the devel list re fastaxes?

    I am glad some one is looking into ways to make mpl more efficient/better for interactive work!

  7. jenshnielsen commented on Jan 31, 2015

    @jenshnielsen
    Member

    Fixed by #4050

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.status: confirmed bug

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions