matplotlib-devel Mailing List for matplotlib

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

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
>

On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root <ben...@ou...> wrote:

> On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing <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.

Ben Root

On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing <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

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

>
> Ben Root
>

On Tue, 15 Feb 2011 11:40:01 -0600, Benjamin Root <ben...@ou...> wrote:
> 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 that this is certainly a bug. For instance, I have a short
script which reads a stream of data from stdin and plots in
realtime. Unfortunately this bug made it prohibitively difficult to add
support for scatter plots. I'd definitely appreciate it if this were
fixed.

Cheers,

- Ben

On 02/12/2011 12:11 PM, Michael Albert wrote:
> Greetings!
>
> First, my personal thanks to you good folks who make
> a wonderful tool like matplotlib available.
>
> I am currently trying to build matplotlib-1.0.1 against
> libpng1.5.1, and _png.cpp failed to compile.  Apparently,
> libpng's info_ptr is now opaque, so the code required
> multiple changes of this nature:

Mike,

A quick check indicates that the png_get* functions are available way 
back in libpng 1.2.x, so I suspect we can support everything we need to 
with a single modern version.

Does anyone know of a reason we need to support libpng prior to 1.2.x?

Would you attach your complete diff, please?

Thanks.

Eric


>
> -- _png.cpp.orig 2011-02-12 16:42:42.000000000 -0500
> ***************
> *** 350,362 ****
>        png_set_sig_bytes(png_ptr, 8);
>        png_read_info(png_ptr, info_ptr);
>
> !     /*png_uint_32 width = info_ptr->width;*/
> !     /*png_uint_32 height = info_ptr->height;*/
> !     png_uint_32 width = png_get_image_width( png_ptr, info_ptr );
> !     png_uint_32 height = png_get_image_height( png_ptr, info_ptr );
>
> !     /*int bit_depth = info_ptr->bit_depth;*/
> !     int bit_depth = png_get_bit_depth( png_ptr, info_ptr );
>
>        // Unpack 1, 2, and 4-bit images
>        if (bit_depth<  8)
> --- 350,359 ----
>        png_set_sig_bytes(png_ptr, 8);
>        png_read_info(png_ptr, info_ptr);
>
> !     png_uint_32 width = info_ptr->width;
> !     png_uint_32 height = info_ptr->height;
>
> !     int bit_depth = info_ptr->bit_depth;
>
>        // Unpack 1, 2, and 4-bit images
>        if (bit_depth<  8)
> ***************
>
> Sorry to be sending problems :-).
> I suspect you have probably noticed this
> already, but just in case I figured I'd send
> a "head's up".  Thanks!
>
> Sincerely,
>   Mike Albert
>
>
> ------------------------------------------------------------------------------
> 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

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.

Ben Root

On Mon, Feb 14, 2011 at 6:56 PM, Gökhan Sever <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'
>
> ======================================================================
> 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)
>
> ----------------------------------------------------------------------
> 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

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'

======================================================================
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)

----------------------------------------------------------------------
Ran 152 tests in 71.340s

FAILED (KNOWNFAIL=46, errors=2)
False


-- 
Gökhan