Skip to content

Matplotlib "eats" points when zeros present on logscaled scatter plot #2872

Closed

Description

@andrewcollette

The following script demonstrates the issue with Matplotlib 1.3.1:

import pylab as plt

X = 5  # set X = 0 and matplotlib drops all later points

data1 = [1,2,3,4,5,6,7,8]
data2 = [1,2,3,4,X,6,7,8]

f = plt.figure(0)
plt.scatter(data1, data2)
plt.xscale('log')
plt.yscale('log')
plt.show()

The problem occurs when using a scatter plot with logscaled axes; if zeros are present in the data, a substantial fraction of the points are discarded. Obviously zeros can't be displayed on a log plot, but I would have expected those points (and only those points) to be silently dropped, or at worst an exception be raised.

Activity

  1. Tillsten commented on Mar 6, 2014

    @Tillsten
    Contributor

    Not happing here, also 1.3.1.

  2. andrewcollette commented on Mar 6, 2014

    @andrewcollette
    Author

    If it helps, this is on OS X (10.9.2); matplotlib installed via pip.

  3. tacaswell commented on Mar 6, 2014

    @tacaswell
    Member

    What backend are you using?

    I can not reproduce this on master (linux, pyqt)

  4. andrewcollette commented on Mar 6, 2014

    @andrewcollette
    Author

    The backend is "MacOSX", Python 2.7.6.

  5. tacaswell commented on Mar 6, 2014

    @tacaswell
    Member

    @mdehoon, @cimarronm, @efiring Can one of you take a look at this? I suspect this is a macosx backend bug. I do not have easy access to a mac for testing this.

  6. efiring commented on Mar 6, 2014

    @efiring
    Member

    I can't reproduce this with macosx backend, master, python 2.7.3, numpy 1.7.0.

  7. andrewcollette commented on Mar 6, 2014

    @andrewcollette
    Author

    Some more information:

    NumPy 1.8.0

    WXAgg and TKAgg work correctly (the troublesome point is simply skipped), as does "Agg" and using savefig() to output a PDF file.

  8. jenshnielsen commented on Mar 6, 2014

    @jenshnielsen
    Member

    I can reproduce it with the MacOS backend on 1.3.1. Works as expected using the QT backend.

  9. efiring commented on Mar 6, 2014

    @efiring
    Member

    @jenshnielsen what is your numpy version?

  10. cimarronm commented on Mar 6, 2014

    @cimarronm
    Contributor

    I cannot reproduce with MacOS backend on master, numpy 1.8.0 and python 3.3.4

  11. jenshnielsen commented on Mar 6, 2014

    @jenshnielsen
    Member

    Numpy 1.8.1rc1 and python2.7

  12. efiring commented on Mar 6, 2014

    @efiring
    Member

    OK it is not numpy. I also tried 1.8.1rc1 and python 2.7, and with mpl master I can't reproduce it. I hope this means that whatever it is, it is already fixed in master.

  13. andrewcollette commented on Mar 6, 2014

    @andrewcollette
    Author

    I did some further testing: on my system this bug IS present in the v1.3.x branch (8863ac), and IS NOT present in master (93de06).

  14. Tillsten commented on Mar 7, 2014

    @Tillsten
    Contributor

    Maybe fixed with #1886?

  15. efiring commented on Mar 7, 2014

    @efiring
    Member

    Given that this is fixed in master, that a release from master is in the works, and that it is not clear whether there will be another 1.3 release, I am closing this.

  16. mdehoon commented on Mar 7, 2014

    @mdehoon
    Contributor

    The bug is being caused by the argument "offsets" in the call to gc.draw_path_collection. This argument contains NaN's if the log(0) data point is included. If we can assume that gc.draw_path_collection and other functions always receive valid arguments (i.e., not containing NaN's), then we can consider this bug fixed. However, if we cannot make that assumption, then gc.draw_path_collection contains a bug. It's fairly easy to fix gc.draw_path_collection such that NaN's are avoided (should they occur in the input arguments), but it may affect the drawing speed performance, so I'd be happier if we can assume that there won't be NaN's in the input arguments to drawing functions.

  17. efiring commented on Mar 7, 2014

    @efiring
    Member

    From Collection._prepare_points() I conclude that a NaN is the intended marker for a missing value in offsets. Now, the question is why this causes a problem in 1.3.1 but not in master.

  18. mdehoon commented on Mar 7, 2014

    @mdehoon
    Contributor

    Two reasons:

    1. In master, draw_markers is used instead of draw_path_collection. The draw_markers function treats NaN's correctly, should they arise.
    2. In draw_markers, the X=0 causes the dot to get a negative coordinate (and therefore is not displayed), instead of a NaN.
      I'll prepare a patch to fix draw_path_collection. It would be good if somebody has a look at why a negative coordinate appears there.
  19. added a commit that references this issue on Mar 7, 2014
  20. tacaswell commented on Mar 7, 2014

    @tacaswell
    Member

    Some what recently there was a change in how clipping for log plots worked, that might be related.

  21. added a commit that references this issue on Mar 11, 2014
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

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions