matplotlib-devel Mailing List for matplotlib (Page 6)

Hi,

I tried to use "edgecolor = 'none'" in a call to bar(), hoping to get no
border to the bars, but instead got no bars at all.  The patch below
(against 1.0.0) seems to fix this; it adds a check for 'none' to the
existing check for None as a special case of the edgecolor argument.

Thanks,

Ben.




--- ORIG-axes.py        2010-07-06 15:43:35.000000000 +0100
+++ NEW-axes.py 2010-08-09 09:16:51.000004000 +0100
@@ -4582,8 +4582,9 @@
             if len(color) < nbars:
                 color *= nbars

-        if edgecolor is None:
-            edgecolor = [None] * nbars
+        if (edgecolor is None
+            or (is_string_like(edgecolor) and edgecolor.lower() == 'none')):
+            edgecolor = [edgecolor] * nbars
         else:
             edgecolor = list(mcolors.colorConverter.to_rgba_array(edgecolor))
             if len(edgecolor) < nbars:

Hi,

While looking at axes.py for the color/edgecolor patch just sent, I
noticed the FIXME suggesting ValueError instead of assert.  Is the below
the kind of thing?

Ben.




--- ORIG-axes.py        2010-07-06 15:43:35.000000000 +0100
+++ NEW-axes.py 2010-08-09 09:43:30.000257000 +0100
@@ -4589,15 +4589,12 @@
             if len(edgecolor) < nbars:
                 edgecolor *= nbars

-        # FIXME: convert the following to proper input validation
-        # raising ValueError; don't use assert for this.
-        assert len(left)==nbars, "incompatible sizes: argument 'left'
must be length %d or scalar" % nbars
-        assert len(height)==nbars, ("incompatible sizes: argument
'height' must be length %d or scalar" %
-                                    nbars)
-        assert len(width)==nbars, ("incompatible sizes: argument
'width' must be length %d or scalar" %
-                                   nbars)
-        assert len(bottom)==nbars, ("incompatible sizes: argument
'bottom' must be length %d or scalar" %
-                                    nbars)
+        for argname in ['left', 'height', 'width', 'bottom']:
+            arg = locals()[argname]
+            if len(arg) != nbars:
+                raise ValueError("incompatible sizes:"
+                                 " argument '%s' must be length %d or scalar"
+                                 % (argname, nbars))

         patches = []

Hi,

Update to my recent email: perhaps it would make sense to handle the
'color' argument in the same way, allowing hollow bars.  Combined patch
below.

Ben.



--- ORIG-axes.py        2010-07-06 15:43:35.000000000 +0100
+++ NEW-axes.py 2010-08-09 09:39:44.000256000 +0100
@@ -4575,15 +4575,17 @@
         if len(linewidth) < nbars:
             linewidth *= nbars

-        if color is None:
-            color = [None] * nbars
+        if (color is None
+            or (is_string_like(color) and color.lower() == 'none')):
+            color = [color] * nbars
         else:
             color = list(mcolors.colorConverter.to_rgba_array(color))
             if len(color) < nbars:
                 color *= nbars

-        if edgecolor is None:
-            edgecolor = [None] * nbars
+        if (edgecolor is None
+            or (is_string_like(edgecolor) and edgecolor.lower() == 'none')):
+            edgecolor = [edgecolor] * nbars
         else:
             edgecolor = list(mcolors.colorConverter.to_rgba_array(edgecolor))
             if len(edgecolor) < nbars:

Same here with r8611

Ben Root

On Fri, Aug 6, 2010 at 2:36 PM, Gökhan Sever <gok...@gm...> wrote:

> Hello,
>
> Just reporting if all is good with the mpl test suite.
>
> >>> import matplotlib
> >>> matplotlib.test()
> /home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/axes.py:2377:
> 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: matplotlib.tests.test_axes.test_pcolormesh
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, 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_axes/pcolormesh.png vs.
> /home/gsever/Desktop/result_images/test_axes/expected-pcolormesh.png (RMS
> 116.512)
>
> ----------------------------------------------------------------------
> Ran 147 tests in 111.461s
>
> FAILED (KNOWNFAIL=45, errors=1)
> False
>
> ================================================================================
> Platform     :
> Linux-2.6.31.9-174.fc12.i686.PAE-i686-with-fedora-12-Constantine
> Python       : ('CPython', 'tags/r262', '71600')
> Matplotlib   : 1.0.0-rev8624
>
> ================================================================================
>
> Interestingly, when I try to run the test suite in IPython v0.10 it stops
> without executing the tests:
>
> In[9]: matplotlib.test()
> Usage: ipython [options]
>
> ipython: error: no such option: -y
> ---------------------------------------------------------------------------
> SystemExit                                Traceback (most recent call last)
> ...
>
> --
> Gökhan
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Fri, Aug 6, 2010 at 3:33 PM, Damon McDougall
<D.M...@wa...>wrote:

> Hi all,
>
> Don't know if anybody else has found a colormap that is aesthetically
> pleasing and prints well in black and white. I found one after a lot of
> Googling. Perhaps useful for plotting figures in journals that charge a lot
> for colour figures. I got the colormap from:
> http://ieeexplore.ieee.org/iel5/74/22101/01028735.pdf%3Farnumber%3D1028735
>
> I decided to code it up (see attached text file for the cdict). If anybody
> finds it useful, maybe it could go into the default colormaps that ship with
> matplotlib.
>
>
>
>
> Regards,
> -- Damon
>
> --------------------------
> Damon McDougall
> Mathematics Institute
> University of Warwick
> Coventry
> CV4 7AL
> d.m...@wa...
>
>
Actually, I have been looking at a somewhat related problem.  It might be a
useful feature in matplotlib.color to provide a function that can take a
colormap and produce a grayscale version of it.  In my limited amount of
research, I have found that one could convert the rgb values into hsv or hsl
and use the "value" or "lightness" respectively for the grayscale value.  I
forget which one was aesthetically better, though.

Ben Root

Hi all,

Don't know if anybody else has found a colormap that is aesthetically pleasing and prints well in black and white. I found one after a lot of Googling. Perhaps useful for plotting figures in journals that charge a lot for colour figures. I got the colormap from: http://ieeexplore.ieee.org/iel5/74/22101/01028735.pdf%3Farnumber%3D1028735

I decided to code it up (see attached text file for the cdict). If anybody finds it useful, maybe it could go into the default colormaps that ship with matplotlib.

Hello,

Just reporting if all is good with the mpl test suite.

>>> import matplotlib
>>> matplotlib.test()
/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/axes.py:2377:
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: matplotlib.tests.test_axes.test_pcolormesh
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, 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_axes/pcolormesh.png vs.
/home/gsever/Desktop/result_images/test_axes/expected-pcolormesh.png (RMS
116.512)

----------------------------------------------------------------------
Ran 147 tests in 111.461s

FAILED (KNOWNFAIL=45, errors=1)
False

================================================================================
Platform     :
Linux-2.6.31.9-174.fc12.i686.PAE-i686-with-fedora-12-Constantine
Python       : ('CPython', 'tags/r262', '71600')
Matplotlib   : 1.0.0-rev8624
================================================================================

Interestingly, when I try to run the test suite in IPython v0.10 it stops
without executing the tests:

In[9]: matplotlib.test()
Usage: ipython [options]

ipython: error: no such option: -y
---------------------------------------------------------------------------
SystemExit                                Traceback (most recent call last)
...

-- 
Gökhan

2010/6/15 Olle Engdegård <oen...@gm...>:
> The autoscaling might need a small fix for
>
> hist(rand(100),bins=20,histtype="step",log=1)

I just had a look at trunk (8623), and the lower y-limit looks good
now. The above problem was at rev 8475.

But an old, different, bug has turned up instead: Using "stepfilled"
you get a diagonal lower boundary:

a=[3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6]
hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True)

Cheers,
Olle

On 08/03/2010 07:53 PM, Andrew Straw wrote:
> On 8/1/10 7:11 PM, Eric Firing wrote:
>> On 07/31/2010 08:51 PM, Andrew Straw wrote:
>>
>>> Hi MPL devs,
>>>
>>> I think I've fixed a long-standing issue we've had with the buildbot
>>> where sometimes a false alarm was issued when two tests stepped on each
>>> others' toes. Specifically, I've fixed up the MPL buildbot environment
>>> on the virtual machine that runs both the Python 2.4 and 2.5 tests so
>>> that these tests are run from different MPLCONFIGDIRs.
[...]
>> 2) Can the bug be closed now?
>>
>>
> Yes, I closed it.

Thank you--and more importantly, thanks for all the buildbot work.

Eric

On 8/1/10 7:11 PM, Eric Firing wrote:
> On 07/31/2010 08:51 PM, Andrew Straw wrote:
>    
>> Hi MPL devs,
>>
>> I think I've fixed a long-standing issue we've had with the buildbot
>> where sometimes a false alarm was issued when two tests stepped on each
>> others' toes. Specifically, I've fixed up the MPL buildbot environment
>> on the virtual machine that runs both the Python 2.4 and 2.5 tests so
>> that these tests are run from different MPLCONFIGDIRs.
>>      
> Andrew et al,
>
> https://sourceforge.net/tracker/?func=detail&aid=2856125&group_id=80706&atid=560720
>
> Please see my comment in the above bug ticket.  I'm curious about three
> things:
>
> 1) Would the solution I suggested in that comment also have worked?  If
> so, would it be more robust against future changes in the buildbot, or
> the creation of new buildbots?  Or was I misunderstanding where the
> buildbot code comes from, and how it works?
>    
Your comment on the tracker was:

> Having two buildbot processes
> accessing, and potentially writing to, the same cache file(s) partly
> defeats the purpose of the buildbot: testing independent builds
> independently, on a variety of systems.

The fact that we have two simultaneous build/test cycles happening on 
one test system is simply a result of the way I configured the buildbot. 
(I'm running a Python 2.4 and Python 2.5 interpreter simultaneously on 
the same machine.) I wouldn't call it a failure of the buildbot software 
at all.

The solution you proposed in the comment was close to what I 
implemented. The difference is I didn't use tempfile.mkdtemp but just 
fixed the value per buildbot slave.

> 2) Can the bug be closed now?
>
>    
Yes, I closed it.

>> So, from now on, all emails from the buildbot should be taken seriously.
>>      
> 3) What about the failure that occurred after your 8609 commit?
If you look at the log, that was because there was trouble downloading 
pygments. (I should disable networking on the build slaves, but 
haven't...) The next build didn't have that issue.

>    It
> looks like the scons build is not being run, but it's last failure (in
> November) is still triggering the email.  Correct?
>    
No, the buildbot is currently configured only to send a single email on 
the transition from OK -> failure for a given slave. So there was one 
email sent about this, but shouldn't be any more.

So, again,  we can take all emails from the buildbot seriously.

2010/8/3 John Hunter <jd...@gm...>:
> On Tue, Aug 3, 2010 at 3:29 PM, Friedrich Romstedt
> <fri...@gm...> wrote:
>> I prepared a png 64x64 version of the icon using Inkscape.  See attachment.
>
> Our other pngs for icons are 24x24.  Can you provide on in that size?

Sure

Friedrich

On Tue, Aug 3, 2010 at 3:29 PM, Friedrich Romstedt
<fri...@gm...> wrote:
> 2010/8/3 Sebastian Voigt <Seb...@ma...>:
>> I've seen that NavigationToolbar2QT uses a mixture of svg and png icons.
>> All icons except the <qt4_editor_options> icon are provided in svg as
>> well as png format. Can you add a png version of this icon?
>
> I prepared a png 64x64 version of the icon using Inkscape.  See attachment.

Our other pngs for icons are 24x24.  Can you provide on in that size?

JDH

2010/8/3 Sebastian Voigt <Seb...@ma...>:
> I've seen that NavigationToolbar2QT uses a mixture of svg and png icons.
> All icons except the <qt4_editor_options> icon are provided in svg as
> well as png format. Can you add a png version of this icon?

I prepared a png 64x64 version of the icon using Inkscape.  See attachment.

Friedrich

Hi,

I've seen that NavigationToolbar2QT uses a mixture of svg and png icons. 
All icons except the <qt4_editor_options> icon are provided in svg as 
well as png format. Can you add a png version of this icon?

Background: I'm using pythonxy and built my stuff including a Qt 
MatplotlibWidget + Toolbar with py2exe. The resulting application only 
supports png images so I changed the icons in backend_qt4 to *.png but 
the <qt4_editor_options> icon cannot be displayed this way. Maybe I 
could recompile PyQt4 with svg support but this is not really an option 
since I don't know how to do this.

Regards,
Sebastian

-- 
_________________________________________________________________

Dipl.-Ing. Sebastian Voigt

Technische Universität Dresden
Institut für Verarbeitungsmaschinen und Mobile Arbeitsmaschinen
D-01062 Dresden

Thanks for pointing this out.  It is now fixed (and I added your example 
as a regression test).

Mike

On 08/01/2010 10:49 PM, Jae-Joon Lee wrote:
> Michael,
>
> In your commit 8585, you added an extra apply_translation command in
> the make_image function (line 594 of image.py, note that there is
> another one at line 599).
>
> Currently, imshow command places image in wrong place (except when
> interpolation is nearest ) and I think this is because of the extra
> translation.
>
> Tor reproduce the problem,
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> arr = np.arange(100).reshape((10, 10))
> plt.imshow(arr, interpolation="bilinear", extent=(1,2,1,2))
> plt.xlim(0,3)
> plt.ylim(0,3)
> plt.show()
>
> The image are not at what it meant to be.
>
> Removing one of the translation solves the problem. And I guess that
> line is there by mistake?
> Can you check this and commit the fix if possible.
>
> Regards,
>
> -JJ
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> 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

Michael,

In your commit 8585, you added an extra apply_translation command in
the make_image function (line 594 of image.py, note that there is
another one at line 599).

Currently, imshow command places image in wrong place (except when
interpolation is nearest ) and I think this is because of the extra
translation.

Tor reproduce the problem,

import numpy as np
import matplotlib.pyplot as plt

arr = np.arange(100).reshape((10, 10))
plt.imshow(arr, interpolation="bilinear", extent=(1,2,1,2))
plt.xlim(0,3)
plt.ylim(0,3)
plt.show()

The image are not at what it meant to be.

Removing one of the translation solves the problem. And I guess that
line is there by mistake?
Can you check this and commit the fix if possible.

Regards,

-JJ

On 07/31/2010 08:51 PM, Andrew Straw wrote:
> Hi MPL devs,
>
> I think I've fixed a long-standing issue we've had with the buildbot
> where sometimes a false alarm was issued when two tests stepped on each
> others' toes. Specifically, I've fixed up the MPL buildbot environment
> on the virtual machine that runs both the Python 2.4 and 2.5 tests so
> that these tests are run from different MPLCONFIGDIRs.

Andrew et al,

https://sourceforge.net/tracker/?func=detail&aid=2856125&group_id=80706&atid=560720

Please see my comment in the above bug ticket.  I'm curious about three 
things:

1) Would the solution I suggested in that comment also have worked?  If 
so, would it be more robust against future changes in the buildbot, or 
the creation of new buildbots?  Or was I misunderstanding where the 
buildbot code comes from, and how it works?

2) Can the bug be closed now?

>
> So, from now on, all emails from the buildbot should be taken seriously.

3) What about the failure that occurred after your 8609 commit?  It 
looks like the scons build is not being run, but it's last failure (in 
November) is still triggering the email.  Correct?

Thanks.

Eric


>
>
> As a reminder, you can see the buildbot waterfall output at:
> http://mpl-buildbot.code.astraw.com/waterfall
>
> You can sign up for the buildbot mailing list at:
> https://lists.sourceforge.net/lists/listinfo/matplotlib-buildbot
>
> And the main MPL buildbot page is:
> http://mpl-buildbot.code.astraw.com
>
> -Andrew

Hi MPL devs,

I think I've fixed a long-standing issue we've had with the buildbot 
where sometimes a false alarm was issued when two tests stepped on each 
others' toes. Specifically, I've fixed up the MPL buildbot environment 
on the virtual machine that runs both the Python 2.4 and 2.5 tests so 
that these tests are run from different MPLCONFIGDIRs.

So, from now on, all emails from the buildbot should be taken seriously.


As a reminder, you can see the buildbot waterfall output at:
http://mpl-buildbot.code.astraw.com/waterfall

You can sign up for the buildbot mailing list at:
https://lists.sourceforge.net/lists/listinfo/matplotlib-buildbot

And the main MPL buildbot page is:
http://mpl-buildbot.code.astraw.com

-Andrew