Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

[Eric Firing]

On 08/26/2010 05:13 PM, Brian Granger wrote:
> Hi,
>
> We are in the process of getting our new Qt IPython GUI working with
> matplotlib.  One problem we have found is that the matplotlib qt4
> backend always creates a QApplication.  This is problematic in
> situations where another part of an application has already created a
> QApplication.  The fix is to have matplotlib first see if a
> QApplication already exists and then use that one.  The attached patch
> implements this fix.  If needed, Fernando can help test this, but I
> think the change is minor enough that it should be good to go.

I committed it.

I suspect the most recent changes to ipython may require changes to 
show, but they can wait until things settle down a bit.

Eric

>
> Cheers,
>
> Brian

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] plotting an arrow outside of the plot does not work any more

[Benjamin Root]

On Fri, Aug 27, 2010 at 7:21 AM, Stan Schymanski wrote:

> Dear all,
>
> I don't know which update it was that broke it, but this used to work:
>
> import numpy
> import pylab
> pylab.clf()
> fig = pylab.figure(1,figsize=(8,5))
> ax = fig.add_subplot(111, autoscale_on=False, xlim=(-1,5),
> ylim=(-4,3))
>
> t = numpy.arange(0.0, 5.0, 0.01)
> s = numpy.cos(2*numpy.pi*t)
> line, = ax.plot(t, s, lw=3, color='purple')
> pylab.text(-0.5,3.2,'no data',ha='center')
>
> pylab.annotate('',(-1,3.1),(0,3.1),va='center',ha='center',arrowprops=dict(arrowstyle='<->'))
> pylab.savefig('blah.png')
>
> This used to plot an arrow under the text 'no data' but above the main
> plot. Now this arrow does not appear unless at least part of it is within
> the plotting area. Change one of the '3.1' in the code above to, say, 3.0
> and the whole arrow is displayed. Is this a bug or is there a new way of
> achieving what I want?
>
> Thanks for your help already!
>
> Cheers
> Stan
>
>
I wonder if it was one of the fixes to the clipping code. If I plot this to
the screen and then move the plot so that the "no data" text is in the plot
area, the arrow shows up.

So, the question is... was plotting arrows outside the plot area a bug or a
feature? And, if it was a bug, what about being able to annotate outside the
plot area?

Lastly, whatever the outcome, this example should probably become a test
because it would be a great way to test for obscure broken behavior.

Ben Root

P.S. - cc'ing the devel mailing list here...
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Issue with Ellipses and PatchCollections

[Thomas Robitaille]

Hi,

The following code:

from matplotlib.patches import Ellipse
from matplotlib.collections import PatchCollection
p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)

raises the following exception:

Traceback (most recent call last):
  File "test_patches.py", line 5, in 
p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", 
line 1041, in __init__
facecolors   = [determine_facecolor(p) for p in patches]
  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", 
line 1037, in determine_facecolor
if patch.fill:
AttributeError: 'Ellipse' object has no attribute 'fill'

I have submitted a ticket: 
https://sourceforge.net/tracker/?group_id=80706&atid=560720

Cheers,

Tom
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Issue with Ellipses and PatchCollections

[Ryan May]

On Fri, Aug 27, 2010 at 12:20 PM, Thomas Robitaille
 wrote:
> Hi,
>
> The following code:
>
> from matplotlib.patches import Ellipse
> from matplotlib.collections import PatchCollection
> p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>
> raises the following exception:
>
> Traceback (most recent call last):
>  File "test_patches.py", line 5, in 
>    p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>  File 
> "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 
> 1041, in __init__
>    facecolors   = [determine_facecolor(p) for p in patches]
>  File 
> "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 
> 1037, in determine_facecolor
>    if patch.fill:
> AttributeError: 'Ellipse' object has no attribute 'fill'
>
> I have submitted a ticket: 
> https://sourceforge.net/tracker/?group_id=80706&atid=560720

The obvious fix would be to change from patch.fill to
patch.get_fill(). However, I'm curious how this code got broken.

Eric, any ideas? SVN claims that the last change to that line was done
by you (based on a bug *I* reported)? It apparently worked then:

http://sourceforge.net/mailarchive/message.php?msg_name=487A5AE3.5070500%40gmail.com

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Issue with Ellipses and PatchCollections

[Eric Firing]

On 08/27/2010 09:09 AM, Ryan May wrote:
> On Fri, Aug 27, 2010 at 12:20 PM, Thomas Robitaille
>   wrote:
>> Hi,
>>
>> The following code:
>>
>> from matplotlib.patches import Ellipse
>> from matplotlib.collections import PatchCollection
>> p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>>
>> raises the following exception:
>>
>> Traceback (most recent call last):
>>   File "test_patches.py", line 5, in
>> p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>>   File 
>> "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", 
>> line 1041, in __init__
>> facecolors   = [determine_facecolor(p) for p in patches]
>>   File 
>> "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", 
>> line 1037, in determine_facecolor
>> if patch.fill:
>> AttributeError: 'Ellipse' object has no attribute 'fill'
>>
>> I have submitted a ticket: 
>> https://sourceforge.net/tracker/?group_id=80706&atid=560720
>
> The obvious fix would be to change from patch.fill to
> patch.get_fill(). However, I'm curious how this code got broken.

I broke it here: 
http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/diff/799df584a8df/matplotlib/lib/matplotlib/patches.py

The safest way to fix it--that is, preserving the old behavior of 
patch.fill--would be to make it a property.  I can do that later today 
or tomorrow, or you can go ahead with it.  It would be something of an 
inconsistency, in that for partly historical reasons mpl is based on an 
endless procession of getters and setters, but I don't think it would do 
any harm, and it does preserve the earlier API.  At the same time, it 
would be OK to use get_fill in the PatchCollection--it will work, and it 
is more consistent with typical mpl usage.  So, I think the best fix is 
to make both changes, with a comment in patches.py as to why fill is a 
property.

Eric

>
> Eric, any ideas? SVN claims that the last change to that line was done
> by you (based on a bug *I* reported)? It apparently worked then:
>
> http://sourceforge.net/mailarchive/message.php?msg_name=487A5AE3.5070500%40gmail.com
>
> Ryan
>


--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Issue with linestyles and match_original in PatchCollection

[Thomas Robitaille]

Hi,

It seems that the match_original=True option in PatchCollection does not 
preserve line style. Is this deliberate? If not, here is a patch for 
collections.py:

Index: collections.py
===
--- collections.py  (revision 8664)
+++ collections.py  (working copy)
@@ -1041,6 +1041,7 @@
 facecolors   = [determine_facecolor(p) for p in patches]
 edgecolors   = [p.get_edgecolor() for p in patches]
 linewidths   = [p.get_linewidth() for p in patches]
+linestyles   = [p.get_linestyle() for p in patches]
 antialiaseds = [p.get_antialiased() for p in patches]
 
 Collection.__init__(
@@ -1048,7 +1049,7 @@
 edgecolors=edgecolors,
 facecolors=facecolors,
 linewidths=linewidths,
-linestyles='solid',
+linestyles=linestyles,
 antialiaseds = antialiaseds)
 else:
 Collection.__init__(self, **kwargs)

Cheers,

Tom
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] purpose of 'stepfilled' in hist()?

[Erik Tollerud]

I also completely agree that, ideally, hist/bar/box would get a full
re-write...  A re-write of the hist side of things would be very
useful for me, and something that I might end up doing myself, if I
can find the time.  I haven't really done anything with the bar or box
plots, though, so I'm not sure what needs to be changed there.

But presumably we're stuck with backwards-compatibility for the
existing function... and as it stands now, it's clearly bugged, so I
still think the patch should be applied in the interm.

To address the True/1.0 issue, though: The reason I did it here is not
because True is really a special case - this was just a performance
tweak... The whole code snippet is as follows:

if log is True:
minimum = 1.0
elif log:
minimum = float(log)
else:
minimum = 0.0

You'll note that if I change the "elif log:" to "if log" and remove
the first case completely, the behavior is unchanged, because
float(True) = 1.0 ... that was the reason for the choice of 1 as the
default.  The only reason I'm special-casing "log is True" is because
the default is False, so all other things being equal, the most likely
thing someone would assume who didn't read the docs closely would
assume is that it should be "True" - so it's only a tiny performance
boost for those cases.  Honestly, it's not a big deal - I did it out
of habit due to other projects where you get significant performance
gains by special-casing the default argument.



>>    I realize API changes are a pain, but this seems error-prone from a
>>    user's point of view. If they accidentally use 1 instead of "True" -
>>    common among C or old Python users - suddenly the function does
>>    something startling. (There's also an ambiguity between zero and
>>    False, but that's probably not so serious here.) If I were designing
>>    an API from scratch I'd probably go with a separate parameter for the
>>    minimum (or not, if ylim can fix it after the fact) and a dedicated
>>    one for "should we use a log scale". Failing that, maybe the string
>>    "auto" to indicate automatic minimum values and None for a default?

On Wed, Aug 25, 2010 at 10:06 AM, Eric Firing  wrote:
> On 08/25/2010 04:50 AM, Benjamin Root wrote:
>>
>> On Wed, Aug 25, 2010 at 12:00 AM, Anne Archibald
>> mailto:aarch...@physics.mcgill.ca>> wrote:
>>
>>    On 24 August 2010 22:22, Benjamin Root >    > wrote:
>>     > On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald
>>    mailto:aarch...@physics.mcgill.ca>>
>>     > wrote:
>>     >>
>>     >> On 24 August 2010 19:16, Erik Tollerud >    > wrote:
>>     >> > Whoops, yes, that should be True... Also realized a slight
>>    error in
>>     >> > the description of how the mimum is set - both of those are
>>    fixed in
>>     >> > the attached diff.
>>     >>
>>     >> Um, this is a kind of important point of style: it is much better
>> to
>>     >> use "if foo:" than "if foo is True:" or even "if foo == True:".
>>     >> Long-standing python convention allows things like 1, 7.0, numpy
>>     >> booleans that are true, and nonempty lists to have a value of True.
>>     >> Using "if foo:", this works. Using "if foo is True:", this cannot
>>     >> possibly work; even though 1==True, it is not true that 1 is True.
>>     >> "is" has a very specific meaning that should be used only when
>>     >> appropriate (generally, for None or for mutable objects).
>>
>>    [snip]
>>
>>     > While it probably could be better done, the logic of the entire
>>    if statement
>>     > is to first check to see if someone explicitly set a True value
>>    (default is
>>     > False), and that sets the minimum to 1.0.  Then, if it isn't
>>    explicitly
>>     > True, then it checks to see if it is a numerical value and uses
>>    that value
>>     > to indicate the minimum.  Only if it is None or False does it
>>    then go to the
>>     > last branch which would set minimum to zero.
>>     >
>>     > Maybe it should use a cbook function that test for a numerical value
>>     > explicitly instead and do that first, then have a check for the
>>    Truthiness
>>     > of log?
>>
>>    I realize API changes are a pain, but this seems error-prone from a
>>    user's point of view. If they accidentally use 1 instead of "True" -
>>    common among C or old Python users - suddenly the function does
>>    something startling. (There's also an ambiguity between zero and
>>    False, but that's probably not so serious here.) If I were designing
>>    an API from scratch I'd probably go with a separate parameter for the
>>    minimum (or not, if ylim can fix it after the fact) and a dedicated
>>    one for "should we use a log scale". Failing that, maybe the string
>>    "auto" to indicate automatic minimum values and None for a default?
>>
>>    If you're going to use True to mean something different from 1,
>>    though, I'd make sure to put a warning in the docstring. Unfortunately
>>