matplotlib-devel Mailing List for matplotlib

On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root <ben...@ou...> wrote:
> On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing <ef...@ha...> wrote:
>>
>>> On 02/15/2011 08:50 AM, Benjamin Root wrote:
>>>
>>>> On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root <ben...@ou...
>>>> <mailto:ben...@ou...>> wrote:
>>>>
>>>> On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing <ef...@ha...
>>>> <mailto:ef...@ha...>> wrote:
>>>>
>>>> On 02/15/2011 07:40 AM, Benjamin Root wrote:
>>>> > I have come across a little inconsistency that was unexpected
>>>> in the
>>>> > matplotlib API. The following is perfectly valid:
>>>> >
>>>> > import matplotlib.pyplot as plt
>>>> > plt.plot([], [])
>>>> > plt.show()
>>>> >
>>>> >
>>>> > However, this is not valid:
>>>> >
>>>> > import matplotlib.pyplot as plt
>>>> > plt.scatter([], [])
>>>> > plt.show()
>>>> >
>>>> >
>>>> > The immediate issue that comes up in scatter is that it
>>>> attempts to find
>>>> > min/max of the input data for the purpose of autoscaling
>>>> (this can
>>>> > probably be done better by just using set_xmargin(0.05) and
>>>> > set_ymargin(0.05)). This can easily be bypassed with an if
>>>> statement.
>>>> > However, then we discover that polygon collection do not like
>>>> having
>>>> > empty offsets, which leads to a failure in the affine
>>>> transformation.
>>>> >
>>>> > So, the question is, is this a bug or a feature? I
>>>> personally believe
>>>> > that empty data is a perfectly valid scenario and given that
>>>> other
>>>> > matplotlib functions handle it gracefully, we should make the
>>>> > collections object more friendly to empty data.
>>>>
>>>> I agree; a call with empty data should simply not plot anything.
>>>>
>>>> Eric
>>>>
>>>>
>>>> Digging further, it appears that the problem is in _path.cpp for
>>>> _path_module::affine_transform() which explicitly checks for an
>>>> empty vertices array and throws an exception if it is empty.
>>>>
>>>> So, do we want to make _path.cpp empty-friendly or should we just
>>>> make empty collections objects just avoid doing anything that
>>>> requires doing an affine transform?
>>>>
>>>> Ben Root
>>>>
>>>>
>>>>
>>>> Ok, some more digging deepens the mystery. While an empty-friendly
>>>> _path.cpp would be nice, it appears that the collections and axes
>>>> objects are already doing all it can to avoid doing transforms for empty
>>>> collections.
>>>>
>>>> However, it appears that the supposedly empty collection object from
>>>> scatter([], []) is not really empty. Its self._paths member contains a
>>>> list of unit_circle() from Path. This is also the case for
>>>> EllipseCollection. Meanwhile, LineCollection and PatchCollection
>>>> initializes their self._paths in accordance to their given data.
>>>>
>>>
>>> One way to solve the problem would be to start each draw() method with a
>>> short-circuit return in case there is nothing to draw. It would be needed
>>> only for classes for which empty self._paths is not a valid test. So for
>>> CircleCollection it would be:
>>>
>>> @allow_rasterization
>>> def draw(self, renderer):
>>> # sizes is the area of the circle circumscribing the polygon
>>> # in points^2
>>> if len(self._sizes) == 0:
>>> return
>>> self._transforms = [
>>> transforms.Affine2D().scale(
>>> (np.sqrt(x) * self.figure.dpi / 72.0) / np.sqrt(np.pi))
>>> for x in self._sizes]
>>> return Collection.draw(self, renderer)
>>>
>>> (Collection.draw returns nothing, so there is no inconsistency in the
>>> return value.)
>>>
>>> Alternatively, it looks like maybe an empty self._transforms could be
>>> used in a short-circuit test at the start of Collection.draw.
>>>
>>> Eric
>>>
>>>
>>>
>>>> Ben Root
>>>>
>>>>
>>>
>> That wouldn't completely solve the problem. Affine transforms are being
>> done for get_datalim() as well. The other issue (and I see that I mixed
>> this up myself) is the assumption elsewhere that a non-empty self._path
>> attribute means that there is something to plot. This is an assumption that
>> is made in axes.py on line 1413 and it is an invalid assumption.
>>
>> As for your proposed solution in draw(), I prefer short-circuiting in
>> Collections.draw(). This makes for less work for new Collection subclasses.
>>
>> Ben Root
>>
>
>
> Working from an assumption that we can't possibly find all bad/broken
> assumptions in mpl, I decided to go the route of Eric and make the
> Collections object as robust as possible. I have attached a patch that
> should enable empty scatter plots in matplotlib and enable empty Collections
> as well.
>
> This has not been fully tested yet. Please be brutal!
>
> Ben Root
>
>
>
Heh, looks like that patch breaks the plotting of errorbars (the line
connecting the center point to the error caps is missing).
I will see about fixing that.
Ben Root

On 02/14/2011 08:32 PM, Benjamin Root wrote:
> On Mon, Feb 14, 2011 at 6:56 PM, Gökhan Sever <gok...@gm... 
> <mailto:gok...@gm...>> wrote:
>
> python
> Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
> [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import matplotlib
> >>> matplotlib.test()
> Warning: divide by zero encountered in log
> Warning: divide by zero encountered in log
> Warning: divide by zero encountered in log
> /home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/axes.py:2389:
> UserWarning: Attempting to set identical left==right results
> in singular transformations; automatically expanding.
> left=730139.0, right=730139.0
> + 'left=%s, right=%s') % (left, right))
> ======================================================================
> ERROR: Failure: IOError ([Errno 2] No such file or directory:
> '/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png')
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/site-packages/nose-1.0.0-py2.7.egg/nose/loader.py",
> line 231, in generate
> for test in g():
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/testing/decorators.py",
> line 91, in compare_images_generator
> shutil.copyfile(src,dst)
> File "/usr/lib64/python2.7/shutil.py", line 81, in copyfile
> with open(src, 'rb') as fsrc:
> IOError: [Errno 2] No such file or directory:
> '/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png'
>
This test was added by John Hunter fairly recently. I'll go ahead and 
commit the test results from my machine -- I assume they are correct 
since there's nothing special about the test.
>
>
> ======================================================================
> ERROR: make the basic nearest, bilinear and bicubic interps
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/site-packages/nose-1.0.0-py2.7.egg/nose/case.py",
> line 187, in runTest
> self.test(*self.arg)
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/testing/decorators.py",
> line 32, in failer
> result = f(*args, **kwargs)
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/testing/decorators.py",
> line 126, in decorated_compare_images
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /home/gsever/Desktop/result_images/test_image/image_interps_pdf.png vs.
> /home/gsever/Desktop/result_images/test_image/expected-image_interps_pdf.png
> (RMS 281.963)
>
Both the png and svg versions of this test have been updated more 
recently than the pdf, so I suspect it's ok to update it. I'll go ahead 
and do this.
Mike
>
>
> ----------------------------------------------------------------------
> Ran 152 tests in 71.340s
>
> FAILED (KNOWNFAIL=46, errors=2)
> False
>
>
> -- 
> Gökhan
>
>
> I have reported that first error a few months ago, and nobody has 
> commented on it. I hope somebody knows what image that is supposed to 
> be for.
>
> The second error has popped up several times before, and we don't seem 
> to address it properly. The difference between the expected and the 
> resulting images has a definite structure to it, suggesting that 
> something changed. Either there is something wrong with the original 
> image, or there is something wrong with the current image. If we 
> figure that the current image is correct, and that there was something 
> wrong with the previous image, then we should update the image in the 
> test suite.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 02/16/2011 03:53 PM, John Hunter wrote:
> On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom<md...@st...> wrote:
>> Not sure Sourceforge allows custom hooks in SVN.
> We have a couple in place already
>
>
> https://sourceforge.net/project/admin/svn.php?group_id=80706
Yes. But those aren't custom -- SF only provides a fixed set of scripts 
one can apply. Notably, I don't think there's one that prevents further 
commits.
Mike