matplotlib-users Mailing List for matplotlib (Page 2)

TheLonelyStar wrote:
> Hi,
>
> I am trying to get the exaple from here:
> http://matplotlib.sourceforge.net/examples/animation/animate_decay_tk_blit.html
>
> I copied it into a file and tried to execute it.
> I get:
>
> File "test.py", line 56, in <module>
> manager.window.after(100, run)
> AttributeError: 'gtk.Window' object has no attribute 'after'
>
> What is wrong? How can I correct that?
>
> Thanks!
> Nathan
> 
Nathan: You're using the GTKAgg backend (the default), whereas the 
script expects the TkAgg backend. Either edit your matplotlibrc file to 
set TkAgg as your default backend, or run the script like this:
python animate_decay_tk_blit.py -dTkAgg
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony S Yu wrote:
> On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
>> Tony S Yu wrote:
>>> Hey Dominik,
>>>
>>> I'd also like to see the default color_cycle be customizeable. But, if
>>> I'm not mistaken, this approach doesn't quite do what you want (at least
>>> it doesn't on a recent version of mpl). The problem is that the color
>>> given by lines.color (rcParam) sort of overrides the first color in the
>>> specified color cycle (see
>>> ``_process_plot_var_args._clear_color_cycle`` in axes.py). 
>>>
>>> It seems important for lines.color and the first color in the color
>>> cycle to match since this matching is also enforced in
>>> ``axes.set_default_color_cycle``, except in reverse (the first color in
>>> the color cycle overrides line.color). If both lines.color and
>>> axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
>>> be issues with how to match the two (e.g. which takes precedence if they
>>> differ).
>>>
>>> As I said earlier, I'd like to see this change made, but I think it may
>>> change the current behavior. Maybe a mpl developer could weigh in?
>>>
>>> -Tony
>> Hi Tony,
>> You are correct, line color overrides the first cycle color. That does
>> not appear a very happy choice to me but this way or another you can
>> still specify BOTH lines.color and the cycle in the param file to get
>> whatever you want, no?
>>
>> Dominik
> 
> Yup, that should do exactly what you want. But, since it's a bit of a hack (you should only need to make 1 change to matplotlibrc), I doubt this patch would be appropriate for the main distribution. 
> 
> Ideally, we'd need to figure out if the matplotlibrc changes 1) only lines.color and make this the first color in color_cycle, 2) only lines.color_cycle and make the first color override lines.color, or 3) both lines.color and lines.color_cycle (behavior unknown if colors don't match). Unfortunately, I don't see an easy way to tell if rcParams have been changed from their default values. 
Hi Tony,
My patches (there were two!) remove the badly hardcoded definition of
defaultColors in axes.py and instead define default axes.color_cycle in
rcsetup.py (defaulting it to the already established color array
['b','g','r','c','m','y','k']). Now, in axes.py, defaultColors are taken
from rcParams, and not a hardcoded array, so unless you modify your own
rc file, you will get the old behavior. It is if and only if you define
your color_cycle in your own rc file that will do anything new. I do not
see how this introduces any incompatibilities.
Dominik
> 
> Actually, the best case IMO, would be if lines.color was deprecated and lines.color_cycle[0] (or maybe lines.colors[0]) was used in its place. However, this change breaks compatibility.
> 
> -Tony
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAks6bAoACgkQ/EBMh9bUuzJ84QCeIzUXldnM1nn8DPyynPL55Jpz
jAkAn1kOSchjSucIymn7CaNIGM1PrLI5
=Fp00
-----END PGP SIGNATURE-----

Hi,
I am trying to get the exaple from here:
http://matplotlib.sourceforge.net/examples/animation/animate_decay_tk_blit.html
I copied it into a file and tried to execute it.
I get:
File "test.py", line 56, in <module>
 manager.window.after(100, run)
AttributeError: 'gtk.Window' object has no attribute 'after'
What is wrong? How can I correct that?
Thanks!
Nathan
-- 
View this message in context: http://old.nabble.com/Can-not-get-animated-matplotlib-example-to-work-tp26959581p26959581.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Tue, Dec 29, 2009 at 1:47 PM, kamaleon <fra...@ya...> wrote:
>
> Hey all,
> I have a program that contains two parameters
> .......
> beta=0.2
> delta=0.4
> .....
> .....
> in the title of my plot i want the value of the ratio beta/delta=0.5 to
> executed automatically when i run the program.
>
> i need:confused:
>
> title('.......\beta/delta=0.5')
You can use string interpolation with format charcters, eg
 title('beta=%.1f, delta=%.1f'%(beta, delta))
if you want greek letters, you can use mathtext
 title(r'$\beta=%.1f, \delta=%.1f$'%(beta, delta))

Hey all,
I have a program that contains two parameters 
.......
beta=0.2
delta=0.4
.....
.....
in the title of my plot i want the value of the ratio beta/delta=0.5 to
executed automatically when i run the program.
i need:confused:
title('.......\beta/delta=0.5')
how can i do that in matplolib?
cheers
kameleon
-- 
View this message in context: http://old.nabble.com/parameters-values-in-the-title-tp26959072p26959072.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
> Tony S Yu wrote:
>> 
>> Hey Dominik,
>> 
>> I'd also like to see the default color_cycle be customizeable. But, if
>> I'm not mistaken, this approach doesn't quite do what you want (at least
>> it doesn't on a recent version of mpl). The problem is that the color
>> given by lines.color (rcParam) sort of overrides the first color in the
>> specified color cycle (see
>> ``_process_plot_var_args._clear_color_cycle`` in axes.py). 
>> 
>> It seems important for lines.color and the first color in the color
>> cycle to match since this matching is also enforced in
>> ``axes.set_default_color_cycle``, except in reverse (the first color in
>> the color cycle overrides line.color). If both lines.color and
>> axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
>> be issues with how to match the two (e.g. which takes precedence if they
>> differ).
>> 
>> As I said earlier, I'd like to see this change made, but I think it may
>> change the current behavior. Maybe a mpl developer could weigh in?
>> 
>> -Tony
> 
> Hi Tony,
> You are correct, line color overrides the first cycle color. That does
> not appear a very happy choice to me but this way or another you can
> still specify BOTH lines.color and the cycle in the param file to get
> whatever you want, no?
> 
> Dominik
Yup, that should do exactly what you want. But, since it's a bit of a hack (you should only need to make 1 change to matplotlibrc), I doubt this patch would be appropriate for the main distribution. 
Ideally, we'd need to figure out if the matplotlibrc changes 1) only lines.color and make this the first color in color_cycle, 2) only lines.color_cycle and make the first color override lines.color, or 3) both lines.color and lines.color_cycle (behavior unknown if colors don't match). Unfortunately, I don't see an easy way to tell if rcParams have been changed from their default values. 
Actually, the best case IMO, would be if lines.color was deprecated and lines.color_cycle[0] (or maybe lines.colors[0]) was used in its place. However, this change breaks compatibility.
-Tony

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony S Yu wrote:
> 
> On Dec 24, 2009, at 4:21 AM, Dominik Szczerba wrote:
>> OK I started hacking and added a color_cycle property to matplotlibrc.
>> Would you be so kind to add this fix to the official version? Thanks!
>> Dominik
>>
>> $ diff -w axes.py axes.py.org <http://axes.py.org>
>> 135,137c135
>> < # DSZ take defaultColors from rcParams
>> < # defaultColors = ['b','g','r','c','m','y','k']
>> < defaultColors = rcParams['axes.color_cycle']
>> - ---
>>> defaultColors = ['b','g','r','c','m','y','k']
>>
>>
>> $ diff -w rcsetup.py rcsetup.py.org <http://rcsetup.py.org>
>> 442,443d441
>> < # DSZ add color_cycle property
>> < 'axes.color_cycle' : [['b','g','r','c','m','y','k'],
>> validate_stringlist],
>>
>>
>>
>> Add to custom matplotlibrc as e.g.:
>>
>> axes.color_cycle : w, w, w, w, w, w, w
>>
> 
> Hey Dominik,
> 
> I'd also like to see the default color_cycle be customizeable. But, if
> I'm not mistaken, this approach doesn't quite do what you want (at least
> it doesn't on a recent version of mpl). The problem is that the color
> given by lines.color (rcParam) sort of overrides the first color in the
> specified color cycle (see
> ``_process_plot_var_args._clear_color_cycle`` in axes.py). 
> 
> It seems important for lines.color and the first color in the color
> cycle to match since this matching is also enforced in
> ``axes.set_default_color_cycle``, except in reverse (the first color in
> the color cycle overrides line.color). If both lines.color and
> axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
> be issues with how to match the two (e.g. which takes precedence if they
> differ).
> 
> As I said earlier, I'd like to see this change made, but I think it may
> change the current behavior. Maybe a mpl developer could weigh in?
> 
> -Tony
Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?
Dominik
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAks5v1QACgkQ/EBMh9bUuzL78ACdGfWMvHSI51CaH0VAWkHyL3E2
EfoAn1tdz6JBEFdlIQW78EkoqwW3hP9E
=0VzO
-----END PGP SIGNATURE-----

On Dec 24, 2009, at 4:21 AM, Dominik Szczerba wrote:
> OK I started hacking and added a color_cycle property to matplotlibrc.
> Would you be so kind to add this fix to the official version? Thanks!
> Dominik
> 
> $ diff -w axes.py axes.py.org
> 135,137c135
> < # DSZ take defaultColors from rcParams
> < # defaultColors = ['b','g','r','c','m','y','k']
> < defaultColors = rcParams['axes.color_cycle']
> - ---
>> defaultColors = ['b','g','r','c','m','y','k']
> 
> 
> $ diff -w rcsetup.py rcsetup.py.org
> 442,443d441
> < # DSZ add color_cycle property
> < 'axes.color_cycle' : [['b','g','r','c','m','y','k'],
> validate_stringlist],
> 
> 
> 
> Add to custom matplotlibrc as e.g.:
> 
> axes.color_cycle : w, w, w, w, w, w, w
> 
Hey Dominik,
I'd also like to see the default color_cycle be customizeable. But, if I'm not mistaken, this approach doesn't quite do what you want (at least it doesn't on a recent version of mpl). The problem is that the color given by lines.color (rcParam) sort of overrides the first color in the specified color cycle (see ``_process_plot_var_args._clear_color_cycle`` in axes.py). 
It seems important for lines.color and the first color in the color cycle to match since this matching is also enforced in ``axes.set_default_color_cycle``, except in reverse (the first color in the color cycle overrides line.color). If both lines.color and axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would be issues with how to match the two (e.g. which takes precedence if they differ).
As I said earlier, I'd like to see this change made, but I think it may change the current behavior. Maybe a mpl developer could weigh in?
-Tony

On Mon, Dec 28, 2009 at 12:39 AM, Eric Firing <ef...@ha...> wrote:
> So, which way is better? I assume the change is an improvement, because
> the behavior with a list should be the same as with an ndarray.
>
I agree with you.
>
> We could split the recaching up into parts that can be done independently on
> x and y, and the part that has to be done when x and y are both set; this
> would permit the separate x and y parts to be done by set_xdata and
> set_ydata, which would freeze the data at that point, so that later changes
> to the original arrays' contents would not affect the plot. (This would
> also require forcing a copy instead of using asarray; this has a performance
> penalty, but perhaps a negligible one.)
This is similar to what I meant with option 1 in my previous post.
>
> Is it really worth fiddling with this, though? Unless there is a compelling
> reason to change it, I am inclined to leave the present behavior alone until
> the larger design is overhauled, so that unit-handling--which is the cause
> of most of the fuss--is clearly and uniformly confined to a single layer of
> the mpl stack.
>
I don't think I can make any compelling case here (I think this is
more like a design choice and not something that need to be fixed).
And I'm completely fine with leaving it as is.
Anyhow, how about adding some words about this behavior in set_data.
 def set_data(self, *args):
 """
 Set the x and y data.
 ACCEPTS: 2D array (rows are x, y) or two 1D arrays
 Note that a Line2D instatnce keeps a reference to the
 input. If the input is mutable (.e.g, list, numpy array) and
 its content changes after the set_data call, the plot may
 reflect the changes. A following meth:`recache` call will
 prevent it.
 """
Anyhow, the current code looks much cleaner than before,
Thanks.
-JJ
> Eric
>

Hi,
I have a Qt application, where I want to display a matplotlib figure which
is updated from time to time (not mebeded, in its own window).
Now, I do:
import pylab
pylab.ion()
pylab.figure()
within a function of the Qt application. And then I get a segfault.
What is the proper way to do this?
I use matplotlib 0.99.1.1 on gentoo linux.
Thanks!
Nathan
-- 
View this message in context: http://old.nabble.com/matplotlib-figure-within-Qt-Application--%3E-segfault-tp26944171p26944171.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Jae-Joon Lee wrote:
> On Sun, Dec 27, 2009 at 7:31 PM, Eric Firing <ef...@ha...> wrote:
>> I don't understand what your script, below, is intended to do or show. I
>> haven't run it with mpl prior to my change. With the change, it simply
>> draws a single line, or at least that is all I see on the plot.
> 
> Before your change, it draws two different lines.
So, which way is better? I assume the change is an improvement, because 
 the behavior with a list should be the same as with an ndarray.
> 
> Anyhow, another example,
> 
> import matplotlib.pyplot as plt
> 
> ax = plt.subplot(111)
> a = [0, 1]
> l1, = ax.plot(a)
> l1.set_ydata(a)
> a[1] = 0.5
> 
> plt.show()
> 
> The above code draws a line from (0,0) to (1, 0.5), not (0,0) to
> (1,1). And my question is whether we want this behavior.
I don't think it matters much. The present behavior is not unreasonable.
> 
> I think the issue is more subtle. If the recaching is done somehow
> before the mutable data changes, the change has no effect. On the
> other hand, if the recaching is done after the change (as in the above
> example), the change is effective.
We could split the recaching up into parts that can be done 
independently on x and y, and the part that has to be done when x and y 
are both set; this would permit the separate x and y parts to be done by 
set_xdata and set_ydata, which would freeze the data at that point, so 
that later changes to the original arrays' contents would not affect the 
plot. (This would also require forcing a copy instead of using asarray; 
this has a performance penalty, but perhaps a negligible one.)
Is it really worth fiddling with this, though? Unless there is a 
compelling reason to change it, I am inclined to leave the present 
behavior alone until the larger design is overhauled, so that 
unit-handling--which is the cause of most of the fuss--is clearly and 
uniformly confined to a single layer of the mpl stack.
Eric
> 
> Regards,
> 
> -JJ

On Sun, Dec 27, 2009 at 7:31 PM, Eric Firing <ef...@ha...> wrote:
> I don't understand what your script, below, is intended to do or show. I
> haven't run it with mpl prior to my change. With the change, it simply
> draws a single line, or at least that is all I see on the plot.
Before your change, it draws two different lines.
Anyhow, another example,
import matplotlib.pyplot as plt
ax = plt.subplot(111)
a = [0, 1]
l1, = ax.plot(a)
l1.set_ydata(a)
a[1] = 0.5
plt.show()
The above code draws a line from (0,0) to (1, 0.5), not (0,0) to
(1,1). And my question is whether we want this behavior.
I think the issue is more subtle. If the recaching is done somehow
before the mutable data changes, the change has no effect. On the
other hand, if the recaching is done after the change (as in the above
example), the change is effective.
Regards,
-JJ

When I try to save a figure to a file using `savefig`, text in the figure
(x-axis label, y-axis label, etc.) is not saved. Have other people
encountered this problem? I'm using the Enthought Python Distribution 5.1.1
on a 32-bit Windows XP machine.
-- 
View this message in context: http://old.nabble.com/savefig-does-not-save-text-tp26939342p26939342.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Eric Firing wrote:
>> I went ahead and committed (svn rev 8054) changes that I think address 
>> the problem, and that should slightly improve speed as well in some 
>> cases, without slowing anything down in other reasonable cases--unless 
>> there are subtleties I am missing. Or maybe I am missing something 
>> blatant. In any case, if I have fouled it up, I trust it will soon be 
>> evident and the commit can be reverted or fixed.
> 
> 
> Sure enough, the buildbot came up with a problem: it looks like there is 
> a test where my change is causing a line to disappear. I will look into it.
> 
Fixed in 8055.
Eric

> 
> I went ahead and committed (svn rev 8054) changes that I think address 
> the problem, and that should slightly improve speed as well in some 
> cases, without slowing anything down in other reasonable cases--unless 
> there are subtleties I am missing. Or maybe I am missing something 
> blatant. In any case, if I have fouled it up, I trust it will soon be 
> evident and the commit can be reverted or fixed.
Sure enough, the buildbot came up with a problem: it looks like there is 
a test where my change is causing a line to disappear. I will look into it.
Eric

Till Stensitzki wrote:
> Hello,
> i am using a Matplotlib figure as widget, in a PyQt4 programm. 
> Everything works, except "set_autoscale_on(False)".
> Everytime i call a figure axes to plot something, it forgets its 
> autoscale status. Here some code, with axs a subplot of a figure:
> 
> | print axs.get_autoscale_on()
> print axs.get_autoscaley_on()
> print axs.get_autoscalex_on()
> axs.plot(range(100)
> print axs.get_autoscale_on()
> print axs.get_autoscaley_on()
> print axs.get_autoscalex_on()
> |
> 
> returns
> 
> |False
> False
> False
> True
> True
> True
> |
> 
> any help?
I can't reproduce it with svn, doing simple command-line plotting with 
ipython. Do you see this problem if you make a minimal plotting script, 
or only when you embed your widget?
Eric

Jae-Joon Lee wrote:
> On Sun, Dec 27, 2009 at 2:37 PM, Eric Firing <ef...@ha...> wrote:
>> What are the circumstances under which one would call set_data() and not
>> want or need an update?
> 
> If you ask me, I'm +1 to update the plot always. But, apparently, the
> original author of this code wanted to do some checks to avoid
> unnecessary recaching. So, I'm not sure which is better.
> 
> On the other hand, I think there is a general issue of whether the
> current behavior of the cache is broken or not. In the code below,
> the function test_cache() gives different results depending on the
> input is a list or a numpy array. And, to me, this is something that
> needs to be fixed despite it may add a little bit of complication into
> the code.
> 
> I did not want to step into this issue as I didn't write the code, but
> there has been no responses from other developers while this issue (I
> mean, the original issue of set_data not updating the plot) has been
> raised a few times in the mailing list.
I'm glad you called attention to it; I agree that it needed to be addressed.
> 
> So, if Eric and others have any other thoughts, please speak.
I went ahead and committed (svn rev 8054) changes that I think address 
the problem, and that should slightly improve speed as well in some 
cases, without slowing anything down in other reasonable cases--unless 
there are subtleties I am missing. Or maybe I am missing something 
blatant. In any case, if I have fouled it up, I trust it will soon be 
evident and the commit can be reverted or fixed.
I don't understand what your script, below, is intended to do or show. I 
haven't run it with mpl prior to my change. With the change, it simply 
draws a single line, or at least that is all I see on the plot.
Eric
> Regards,
> 
> -JJ
> 
> 
> from matplotlib.pyplot import subplot, show
> import numpy as np
> import matplotlib.lines as mlines
> 
> def test_cache(ax, yy):
> l = mlines.Line2D([0, 1], yy)
> yy[1]=0.7
> ax.add_line(l)
> 
> ax = subplot(111)
> a1 = [0, 1]
> test_cache(ax, a1)
> a2 = np.array([0, 1], dtype="d")
> test_cache(ax, a2)
> 
> show()

Hi all,
I like this patch and it works fine. So if nobody is against including
this, I'll commit it in a few days.
I'll move the example from the class comment to an example script.
Cheers,
Reinier
On Wed, Dec 2, 2009 at 1:40 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Dec 2, 2009 at 4:02 AM, Matthias Michler
> <Mat...@gm...> wrote:
>> Hi Jason, Hi list,
>>
>> First of all let me say I like the EngFormatter of Jason.
>> Are there plans to incorparate it into matplotlib?
>> I cannot find any indication for this in current svn, but I would like to see
>> the EngFormatter in matplotlib. Therefore I tried to include Jasons proposal
>> into the ticker.py as a new class EngFormatter including the
>> method 'self.format_eng'.
>
>
> I am interested in this -i I just missed Jason's original email last
> week so thanks for bringing it back to our attention. Please post
> this as a patch on the tracker
>
> http://sourceforge.net/tracker2/?group_id=80706
>
> since I don't have time to review it right now and I don't want it to
> fall through the cracks.
>
> JDH
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Reinier Heeres
Tel: +31 6 10852639

On Sun, Dec 27, 2009 at 2:37 PM, Eric Firing <ef...@ha...> wrote:
> What are the circumstances under which one would call set_data() and not
> want or need an update?
If you ask me, I'm +1 to update the plot always. But, apparently, the
original author of this code wanted to do some checks to avoid
unnecessary recaching. So, I'm not sure which is better.
On the other hand, I think there is a general issue of whether the
current behavior of the cache is broken or not. In the code below,
the function test_cache() gives different results depending on the
input is a list or a numpy array. And, to me, this is something that
needs to be fixed despite it may add a little bit of complication into
the code.
I did not want to step into this issue as I didn't write the code, but
there has been no responses from other developers while this issue (I
mean, the original issue of set_data not updating the plot) has been
raised a few times in the mailing list.
So, if Eric and others have any other thoughts, please speak.
Regards,
-JJ
from matplotlib.pyplot import subplot, show
import numpy as np
import matplotlib.lines as mlines
def test_cache(ax, yy):
 l = mlines.Line2D([0, 1], yy)
 yy[1]=0.7
 ax.add_line(l)
ax = subplot(111)
a1 = [0, 1]
test_cache(ax, a1)
a2 = np.array([0, 1], dtype="d")
test_cache(ax, a2)
show()

Jae-Joon Lee wrote:
> I just filed a bug related with this.
> 
> https://sourceforge.net/tracker/?func=detail&aid=2917758&group_id=80706&atid=560720
> 
> 
> I think the possible solution could be
> 
> 1) we keep the copied version of the input data as a cache, and
> provide a api to access the cache.
> 2) Or forsce set_[x|y]data to always update.
> 
> My current inclination is the option 1.
> If there is any other opinion, I'll go ahead and make a change in a few days.
> 
> -JJ
Jae-Joon,
I wonder whether things are getting more and more complicated here, for 
no real benefit. The logic even of some of the present code in set_data 
and recache is not immediately clear upon casual inspection. What are 
the circumstances under which one would call set_data() and not want or 
need an update?
Eric
> 
> 
> On Tue, Dec 15, 2009 at 9:12 AM, Antonino Ingargiola <tri...@gm...> wrote:
>> Hi to all,
>>
>> I'm doing a simple animation like this:
>>
>> --
>> ion()
>> x = arange(0,2,0.01)
>> y = zeros_like(x)
>> y[45:55]=1
>> l, = plot(x,y)
>>
>> D = 0.1
>> h = x[1]-x[0]
>> dt = 0.0001;
>>
>> def nabla(v,h):
>> na = zeros_like(v)
>> na[1:-1] = (v[2:]-2*v[1:-1]+v[:-2])
>> na[0],na[-1] = 0,0
>> return na/(h**2)
>>
>> for i in range(1000):
>> y = y + D*nabla(y,h)*dt
>> if i%10 == 0:
>> l.set_ydata(y)
>> draw()
>> --
>>
>> however, changing the line
>>
>> y = y + D*nabla(y,h)*dt with
>>
>> in
>>
>> y += D*nabla(y,h)*dt
>>
>> the plot is not updated anymore. I have to replace l.set_ydata(y) with
>> y.recache() to make the the animation work again.
>>
>> I think this is a bug since the line should be updated even using the
>> += operator.
>>
>> Regards,
>> Antonio
>>
>> ------------------------------------------------------------------------------
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Thu, Dec 24, 2009 at 3:53 PM, per freem <per...@gm...> wrote:
> i want it to eliminate the second
> subplot of the first row and instead make the first subplot on the
> first row take up two plots worth of space,
Matpltlib's subplot does not support it as of now.
There a few work around you may try, but it will at least take a few
tens of lines of code. Attached is a way to do this by patching the
object method, which I personally do not prefer but may be one of the
easiest for normal users.
Also, there is a patch I once worked on, but haven't pushed into the
svn yet (i'm not sure if I ever will). So give it a try if you want.
http://article.gmane.org/gmane.comp.python.matplotlib.general/19097
Regards,
-JJ
import matplotlib.transforms as mtransforms
def expand_subplot(ax, num2):
 update_params_orig = ax.update_params
 ax._num2 = num2 - 1
 def _f(self=ax):
 num_orig = self._num
 self._num = self._num2
 update_params_orig()
 right, top = self.figbox.extents[2:]
 self._num = num_orig
 update_params_orig()
 left, bottom = self.figbox.extents[:2]
 self.figbox = mtransforms.Bbox.from_extents(left, bottom,
 right, top)
 ax.update_params = _f
 ax.update_params()
 ax.set_position(ax.figbox)
ax = subplot(231)
expand_subplot(ax, 2)

Hi, I want to capture mouse and keyboard events on a plot while updating it
in regular intervals.
I succeeded doing both tasks independently however not in combination.
For the updating I use a subthread to analyze the data while the main thread
redraws the plot in a loop. However while redrawing it doesn't capture any
other events. When I put a simple sleep in the redrawing thread it shows the
same behavior.
Is there a way to fix this?

Hello,
I've tried, on Python 2.6 Mac O,ドル to install directly matpltolib with easy_install. I've not successed.
Is-it possible ?
Best regards.
Christophe.

If you want to use it in the example section or anything else, you are 
welcome.
greetings
Till
#!/usr/bin/env python
# embedding_in_qt4.py --- Simple Qt4 application embedding matplotlib 
canvases
# It also shows, that normal plotting is quite slow.
#
# Copyright (C) 2005 Florent Rougon
# 2006 Darren Dale
#
# This file is an example program for matplotlib. It may be used and
# modified with no restriction; raw copies as well as modified versions
# may be distributed without limitation.
import sys, os, random
from PyQt4 import QtGui, QtCore
from numpy import arange, sin, pi
from numpy.random import randn, randint
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as 
FigureCanvas
from matplotlib.figure import Figure
progname = os.path.basename(sys.argv[0])
progversion = "0.1"
class MyMplCanvas(FigureCanvas):
 """Ultimately, this is a QWidget (as well as a FigureCanvasAgg, 
etc.)."""
 def __init__(self, parent=None, width=5, height=4, dpi=100):
 fig = Figure(figsize=(width, height), dpi=dpi)
 self.axes = fig.add_subplot(111)
 # We want the axes cleared every time plot() is called
 self.axes.hold(False)
 self.compute_initial_figure()
 #
 FigureCanvas.__init__(self, fig)
 self.setParent(parent)
 FigureCanvas.setSizePolicy(self,
 QtGui.QSizePolicy.Expanding,
 QtGui.QSizePolicy.Expanding)
 FigureCanvas.updateGeometry(self)
 def compute_initial_figure(self):
 pass
class MyStaticMplCanvas(MyMplCanvas):
 """Simple canvas with a sine plot."""
 def compute_initial_figure(self):
 t = arange(0.0, 3.0, 0.01)
 s = sin(2*pi*t)
 self.axes.plot(t, s)
class MyDynamicMplCanvas(MyMplCanvas):
 """A canvas that updates itself every second with a new plot."""
 def __init__(self, *args, **kwargs):
 MyMplCanvas.__init__(self, *args, **kwargs)
 self.timer = QtCore.QTimer(self)
 QtCore.QObject.connect(self.timer, QtCore.SIGNAL("timeout()"), 
self.update_figure)
 self.timer.start(1000)
 def compute_initial_figure(self):
 self.axes.plot(arange(4), randint(0, 10, 4), 'r')
 def update_figure(self):
 # Build a list of 4 random integers between 0 and 10 (both 
inclusive)
 l = randint(0, 10, 4)
 self.axes.plot(arange(1, 5), l, 'r')
 self.draw()
 
 def stop_timer(self):
 self.timer.stop()
 
 
 
class MyBlittMplCanvas(MyMplCanvas):
 """"A canvas thats updates itself as fast a possible, using blitting."""
 def __init__(self, *args, **kwargs):
 MyMplCanvas.__init__(self, *args, **kwargs)
 
 #self.draw()
 self.old_size = self.axes.bbox.width, self.axes.bbox.height
 self.ax_background = self.copy_from_bbox(self.axes.bbox)
 self.cnt = 0
 self.axes.set_autoscale_on(False)
 #self.draw() 
 self.timer=QtCore.QTimer()
 self.connect(self.timer, QtCore.SIGNAL("timeout()"), 
self.update_figure)
 self.timer.start(0)
 
 def blit(self, bbox=None):
 self.replot = bbox
 l, b, w, h = bbox.bounds
 t = b + h
 self.repaint(l, self.renderer.height-t, w, h)
 
 def compute_initial_figure(self): 
 self.t = arange(0.0, 3.0, 0.01)
 s = sin(2*pi*self.t)+randn(len(self.t))
 self.line=self.axes.plot(self.t, s)[0]
 
 def update_figure(self): 
 current_size = self.axes.bbox.width, self.axes.bbox.height
 if self.old_size != current_size:
 self.old_size = current_size
 self.axes.clear()
 self.axes.grid()
 self.draw()
 self.ax_background = self.copy_from_bbox(self.axes.bbox)
 self.restore_region(self.ax_background, bbox=self.axes.bbox)
 # update the data
 self.line.set_ydata(sin(2*pi*self.t)+randn(len(self.t)))
 
 # just draw the animated artist
 self.axes.draw_artist(self.line)
 # just redraw the axes rectangle
 self.blit(self.axes.bbox)
 
class ApplicationWindow(QtGui.QMainWindow):
 def __init__(self):
 QtGui.QMainWindow.__init__(self)
 self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
 self.setWindowTitle("application main window")
 self.file_menu = QtGui.QMenu('&File', self)
 self.file_menu.addAction('&Quit', self.fileQuit,
 QtCore.Qt.CTRL + QtCore.Qt.Key_Q)
 self.menuBar().addMenu(self.file_menu)
 self.help_menu = QtGui.QMenu('&Help', self)
 self.menuBar().addSeparator()
 self.menuBar().addMenu(self.help_menu)
 self.help_menu.addAction('&About', self.about)
 self.main_widget = QtGui.QWidget(self)
 l = QtGui.QVBoxLayout(self.main_widget)
 sc = MyStaticMplCanvas(self.main_widget, width=5, height=4, dpi=100)
 dc = MyDynamicMplCanvas(self.main_widget, width=5, height=4, 
dpi=100)
 bc = MyBlittMplCanvas(self.main_widget, width=5, height=4, dpi=100)
 stopdc=QtGui.QPushButton("Stop dynamic Timer")
 self.connect(stopdc, QtCore.SIGNAL("clicked()"), dc.stop_timer)
 l.addWidget(sc)
 l.addWidget(dc)
 l.addWidget(stopdc)
 l.addWidget(bc)
 self.main_widget.setFocus()
 self.setCentralWidget(self.main_widget)
 self.statusBar().showMessage("All hail matplotlib!", 2000)
 def fileQuit(self):
 self.close()
 def closeEvent(self, ce):
 self.fileQuit()
 def about(self):
 QtGui.QMessageBox.about(self, "About %s" % progname,
u"""%(prog)s version %(version)s
Copyright \N{COPYRIGHT SIGN} 2005 Florent Rougon, 2006 Darren Dale
This program is a simple example of a Qt4 application embedding matplotlib
canvases.
It may be used and modified with no restriction; raw copies as well as
modified versions may be distributed without limitation."""
% {"prog": progname, "version": progversion})
qApp = QtGui.QApplication(sys.argv)
aw = ApplicationWindow()
aw.setWindowTitle("%s" % progname)
aw.show()
sys.exit(qApp.exec_())
#qApp.exec_()

Phillip M. Feldman wrote:
> Hello Jose-
>
> I searched the Python installation on my computer, but have not been 
> able to find the bluemarble image.
>
> I also followed the link that you provided, but didn't find any images 
> that cover the entire surface of the Earth.
>
> Python Developers-
>
> I'd really like to have an option in Basemap.bluemarble() to select from 
> a set of images, rather than just having a single hardwired image.
> 
You already can.
See the documentation for the warpimage method at 
http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html.
-Jeff
> Phillip
>
> Jose Gomez-Dans wrote:
> 
>> Hi,
>>
>> 2009年12月14日 Dr. Phillip M. Feldman <pfe...@ve... 
>> <mailto:pfe...@ve...>>
>>
>> When I generate a map with a background generated via
>> Basemap.bluemarble(),
>> the background is extremely dark. Is there any way to get a
>> lighter/brighter version? (I've looked at all of the available
>> parameters,
>> but none of them seems to allow for adjustment of the luminance).
>>
>>
>> I find this problem when generating a PDF and viewing it in Linux,but 
>> the on-screen version seems to work fine. One reason for your darkness 
>> might be the actual bluemarble scene. There is one for every month 
>> <http://earthobservatory.nasa.gov/Features/BlueMarble/>, so you can 
>> have a look at the different month and pick u which is better for your 
>> area/application. Another thing you can do is to modify the bluemarble 
>> that comes with matplotlib using the gimp, as it is just an image file 
>> you can edit easily. Starts looking like data cooking, tho' ;-)
>>
>> J 
>>