You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Matplotlib "eats" points when zeros present on logscaled scatter plot #2872
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.
@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.
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.
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.
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.
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.
In master, draw_markers is used instead of draw_path_collection. The draw_markers function treats NaN's correctly, should they arise.
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.
Activity
Tillsten commentedon Mar 6, 2014
Not happing here, also 1.3.1.
andrewcollette commentedon Mar 6, 2014
If it helps, this is on OS X (10.9.2); matplotlib installed via pip.
tacaswell commentedon Mar 6, 2014
What backend are you using?
I can not reproduce this on master (linux, pyqt)
andrewcollette commentedon Mar 6, 2014
The backend is "MacOSX", Python 2.7.6.
tacaswell commentedon Mar 6, 2014
@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.
efiring commentedon Mar 6, 2014
I can't reproduce this with macosx backend, master, python 2.7.3, numpy 1.7.0.
andrewcollette commentedon Mar 6, 2014
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.
jenshnielsen commentedon Mar 6, 2014
I can reproduce it with the MacOS backend on 1.3.1. Works as expected using the QT backend.
efiring commentedon Mar 6, 2014
@jenshnielsen what is your numpy version?
cimarronm commentedon Mar 6, 2014
I cannot reproduce with MacOS backend on master, numpy 1.8.0 and python 3.3.4
jenshnielsen commentedon Mar 6, 2014
Numpy 1.8.1rc1 and python2.7
efiring commentedon Mar 6, 2014
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.
andrewcollette commentedon Mar 6, 2014
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).
Tillsten commentedon Mar 7, 2014
Maybe fixed with #1886?
efiring commentedon Mar 7, 2014
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.
mdehoon commentedon Mar 7, 2014
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.
efiring commentedon Mar 7, 2014
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.
mdehoon commentedon Mar 7, 2014
Two reasons:
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.
Fix for issue matplotlib#2872. In case of missing values (e.g., zeros…
tacaswell commentedon Mar 7, 2014
Some what recently there was a change in how clipping for log plots worked, that might be related.
Merge pull request #2875 from mdehoon/issue2872bugfix