matplotlib-users Mailing List for matplotlib (Page 16)

Thank you, JJ, this solves my problems.
I have one question to your reply:
Jae-Joon Lee wrote:
> 
> col, leg = "b", "test"
> errorbar([1,2,3], [1,2,1],xerr=[0.1, 0.1, 0.1], yerr=[0.1, 0.1, 0.1],
> fmt='.',color=col)
> l2, = plot([],[], "+", color=col)
> l2.remove() # remove from the axes
> 
> legend([l2], [leg])
> 
Does it make a difference whether I remove l2 from the axes or not? I can't
see that it is plotting anything at all so I am curious as to what I am
missing here..
Cheers, Karianne
-- 
View this message in context: http://old.nabble.com/legend%3A-changing-the-text-colour-tp29614647p29632842.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I think the answer is yes (at least for me). A behavior like the one
of ipyhton is fine.
Eric, is DreamPie able to run parallel jobs like IPython or not ?
If not, are you thinking to support a behavior like that ?
I think it is very useful for trying to run parallel jobs
interactively, most of all if you want to test MPI programs.
2010年9月6日 Noam Yorav-Raphael <noa...@gm...>:
> The intended audience of IPython and DreamPie is, I think, quite
> similar. Perhaps DreamPie is more suitable for less computer-savvy
> people, as it is a GUI application and not a terminal-based one.
>
> I've seen that "ipython --pylab" goes to interactive mode by default,
> and has a %run command which runs scripts in non-interactive mode.
> Will a behavior like this be fine?
>
> Thanks,
> Noam
>
>
>
>
> On Fri, Sep 3, 2010 at 10:17 AM, Eric Firing <ef...@ha...> wrote:
>>
>> On 09/02/2010 07:47 PM, Noam Yorav-Raphael wrote:
>> > Hello,
>> >
>> > I'm the developer of DreamPie, a new graphical Python shell (you can
>> > check it out at http://dreampie.sourceforge.net )
>> >
>> > I worked to make it work nicely with matplotlib -- it runs Tk/GTK/Qt
>> > event loops when idle, so if matplotlib is in interactive mode it
>> > works great. I even made DreamPie check if matplotlib in
>> > non-interactive mode is present, and if so it shows you a message
>> > suggesting that you switch to interactive mode.
>> >
>> > Lately I thought that it may be much easier for users if DreamPie
>> > would just switch matplotlib to interactive mode automatically.
>> > However, I'm not entirely comfortable with the idea of changing
>> > settings silently.
>> >
>> > I wanted to ask: what do you think? Are there any cases when you want
>> > to have matplotlib in non-interactive mode in a shell?
>>
>> At least with ipython, yes--the point of non-interactive mode is that
>> the show() function blocks, so it can be used in scripts in which the
>> user is supposed to see a plot, dismiss the window, see another plot,
>> etc. Again, at least with ipython, one wants to be *able* to run scripts
>> exactly as they would run from the command line.
>>
>> Whether this sort of thing matters for DreamPie depends on the intended
>> uses and users.
>>
>> Eric
>>
>> >
>> > Also, are there any other ways in which DreamPie can be made more
>> > matplotlib-friendly?
>> >
>> > Thanks,
>> > Noam
>> >
>> > ------------------------------------------------------------------------------
>> > This SF.net Dev2Dev email is sponsored by:
>> >
>> > Show off your parallel programming skills.
>> > Enter the Intel(R) Threading Challenge 2010.
>> > http://p.sf.net/sfu/intel-thread-sfd
>> > _______________________________________________
>> > Matplotlib-users mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Michele De Stefano
http://www.linkedin.com/in/micdestefano
http://code.google.com/p/mds-utils
http://micheledestefano.xoom.it

The intended audience of IPython and DreamPie is, I think, quite
similar. Perhaps DreamPie is more suitable for less computer-savvy
people, as it is a GUI application and not a terminal-based one.
I've seen that "ipython --pylab" goes to interactive mode by default,
and has a %run command which runs scripts in non-interactive mode.
Will a behavior like this be fine?
Thanks,
Noam
On Fri, Sep 3, 2010 at 10:17 AM, Eric Firing <ef...@ha...> wrote:
>
> On 09/02/2010 07:47 PM, Noam Yorav-Raphael wrote:
> > Hello,
> >
> > I'm the developer of DreamPie, a new graphical Python shell (you can
> > check it out at http://dreampie.sourceforge.net )
> >
> > I worked to make it work nicely with matplotlib -- it runs Tk/GTK/Qt
> > event loops when idle, so if matplotlib is in interactive mode it
> > works great. I even made DreamPie check if matplotlib in
> > non-interactive mode is present, and if so it shows you a message
> > suggesting that you switch to interactive mode.
> >
> > Lately I thought that it may be much easier for users if DreamPie
> > would just switch matplotlib to interactive mode automatically.
> > However, I'm not entirely comfortable with the idea of changing
> > settings silently.
> >
> > I wanted to ask: what do you think? Are there any cases when you want
> > to have matplotlib in non-interactive mode in a shell?
>
> At least with ipython, yes--the point of non-interactive mode is that
> the show() function blocks, so it can be used in scripts in which the
> user is supposed to see a plot, dismiss the window, see another plot,
> etc. Again, at least with ipython, one wants to be *able* to run scripts
> exactly as they would run from the command line.
>
> Whether this sort of thing matters for DreamPie depends on the intended
> uses and users.
>
> Eric
>
> >
> > Also, are there any other ways in which DreamPie can be made more
> > matplotlib-friendly?
> >
> > Thanks,
> > Noam
> >
> > ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

This worked great, thanks so much for your help!
Cheers
Stan
On 8/29/10 2:29 AM, Jae-Joon Lee wrote:
> I just remembered that there has been a bug in old version of
> matplotlib that annotation_clip parameter is not correctly set when
> given as a keyword parameter of "annotate" function. The bug has been
> fixed.
>
> http://www.mail-archive.com/mat...@li.../msg15068.html
>
> As a workaround, use
>
> ann = pylab.annotate('',(-1,3.1),(0,3.1),va='center',ha='center',
> arrowprops=dict(arrowstyle='<->'))
> ann.set_annotation_clip(False)
>
> Regards,
>
> -JJ
> 

 On 9/4/10 5:58 PM, xyz wrote:
> On 02/09/10 00:13, Benjamin Root wrote:
>>
>> I am not sure I understand what you mean. Could you please attach an 
>> image of the problem?
>>
>> Ben Root
>>
> Please find attached a picture of the problem. How is it possible to 
> solve the problems?
>
> This is the code:
> from pylab import *
> import matplotlib.pyplot as plt
>
> x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 
> 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
> y1 = [20, 24, 8, 4, 12, 22, 31, 25, 15, 28, 12, 27, 22, 22, 27, 14, 
> 32, 28, 8, 17, 2, 8, 29, 13, 14, 20, 11, 28, 8]
> y2= [2, 32, 28, 1, 22, 11, 14, 27, 3, 31, 12, 20, 32, 24, 24, 16, 7, 
> 10, 12, 11, 3, 32, 10, 20, 14, 14, 3, 25, 14]
> point_labels1 = ['A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 
> 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 
> 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 
> 'A=1', 'A=1']
> point_labels2 = ['B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 
> 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 
> 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 
> 'B=1', 'B=1']
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
>
> ax.set_title('The red point should be on the path')
>
> plt.plot(x, y1, 'bo', x, y2, 'go')
> ax.grid(True)
>
> maxy = max(max(y1), max(y2))
> maxx = max(x)
>
> ax.set_xlim((0.0, maxx))
> ax.set_ylim((0.0, maxy))
>
> # rotates and right aligns the x labels, and moves the bottom of the
> # axes up to make room for them
> fig.autofmt_xdate()
>
> plt.xticks(range(0, maxx, 1))
>
> plt.yticks(range(0, maxy, 1))
> plt.xlabel('Longitude')
> plt.ylabel('Latitude')
> plt.legend(('Model length', 'Data length'),
> 'best', shadow=True, fancybox=True)
>
> for i, label in enumerate(y1):
> plt.text (x[i], y1[i]+0.2, label,
> horizontalalignment='center' )
>
> for i, label in enumerate(y2):
> plt.text (x[i], y2[i]+0.2, label,
> horizontalalignment='center' )
>
> plt.savefig('test.png')
> plt.show()
>
>
> Thank you in advance.
>
Just make the axes limits a little larger than the range of your data 
(instead of exactly equal to the range). That way your labels will fit.
-Jeff

On 02/09/10 00:13, Benjamin Root wrote:
>
> I am not sure I understand what you mean. Could you please attach an 
> image of the problem?
>
> Ben Root
>
Please find attached a picture of the problem. How is it possible to 
solve the problems?
This is the code:
from pylab import *
import matplotlib.pyplot as plt
x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 
20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
y1 = [20, 24, 8, 4, 12, 22, 31, 25, 15, 28, 12, 27, 22, 22, 27, 14, 32, 
28, 8, 17, 2, 8, 29, 13, 14, 20, 11, 28, 8]
y2= [2, 32, 28, 1, 22, 11, 14, 27, 3, 31, 12, 20, 32, 24, 24, 16, 7, 10, 
12, 11, 3, 32, 10, 20, 14, 14, 3, 25, 14]
point_labels1 = ['A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 
'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 
'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1', 'A=1']
point_labels2 = ['B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 
'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 
'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1', 'B=1']
fig = plt.figure()
ax = fig.add_subplot(111)
ax.set_title('The red point should be on the path')
plt.plot(x, y1, 'bo', x, y2, 'go')
ax.grid(True)
maxy = max(max(y1), max(y2))
maxx = max(x)
ax.set_xlim((0.0, maxx))
ax.set_ylim((0.0, maxy))
# rotates and right aligns the x labels, and moves the bottom of the
# axes up to make room for them
fig.autofmt_xdate()
plt.xticks(range(0, maxx, 1))
plt.yticks(range(0, maxy, 1))
plt.xlabel('Longitude')
plt.ylabel('Latitude')
plt.legend(('Model length', 'Data length'),
 'best', shadow=True, fancybox=True)
for i, label in enumerate(y1):
 plt.text (x[i], y1[i]+0.2, label,
 horizontalalignment='center' )
for i, label in enumerate(y2):
 plt.text (x[i], y2[i]+0.2, label,
 horizontalalignment='center' )
plt.savefig('test.png')
plt.show()
Thank you in advance.

Hi,
Is there a way to prevent the matplotlib install from trying to compile for ppc for the c++ compiler? I usually set
export MACOSX_DEPLOYMENT_TARGET=10.6
export CFLAGS="-arch i386 -arch x86_64"
export CPPFLAGS="-arch i386 -arch x86_64"
export FFLAGS="-arch i386 -arch x86_64"
export LDFLAGS="-Wall -undefined dynamic_lookup -bundle -arch i386 -arch x86_64"
before installing packages, and make.osx has:
MACOSX_DEPLOYMENT_TARGET=10.6
OSX_SDK_VER=10.6
ARCH_FLAGS="-arch i386-arch x86_64"
All the gcc commands look like
gcc-4.0 -DNDEBUG -g -O3 -arch i386 -arch x86_64 [...] -isysroot /Developer/SDKs/MacOSX10.6.sdk [...]
but the c++ commands look like
c++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk [...] -arch i386 -arch x86_64 -L/Users/tom/install/tmp/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 [...]
which leads to an error when compiling _tkagg.so:
ld: in /Users/tom/install/tmp/lib/libz.1.dylib, missing required architecture ppc in file for architecture ppc
collect2: ld returned 1 exit status
If I try removing "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" from the compile command, _tkagg.so compiles fine.
Any ideas?
Thanks!
Tom

On Fri, Sep 3, 2010 at 11:04 PM, karianne <kar...@as...> wrote:
> Hi,
>
> I am plotting several different symbols using 3 different colours. The
> colours indicate different data sets, whereas the symbols need not be
> explained. I would therefore like each label to have a different colour,
> i.e. each line in my legend should be written in a different colour
> specified. The legend is getting too long if I have to indicate what each
> symbol represents, plus it would be a repetition of the 3 data sets in
> question. How can I change the colour of the text in the legend?
Do something like
l1, = plot([1,2,3])
leg = legend([l1], ["Test"])
leg_texts = leg.get_texts() # list of matplotlib Text instances.
leg_texts[0].set_color("b")
>
> Second, how can I change the marker in the legend? I am plotting using
> errorbar(), but the marker shows up as a dot, and I would like it to show up
> as a '+', without having to change the actual dots in the plot.
I think it is best to use a proxy artist.
http://matplotlib.sourceforge.net/users/legend_guide.html#using-proxy-artist
For example,
col, leg = "b", "test"
errorbar([1,2,3], [1,2,1],xerr=[0.1, 0.1, 0.1], yerr=[0.1, 0.1, 0.1],
 fmt='.',color=col)
l2, = plot([],[], "+", color=col)
l2.remove() # remove from the axes
legend([l2], [leg])
IHTH,
-JJ
ps. A code snippet, that cannot be run standalone, is not very useful.
If you do not want to post your own data, use some fake data.

On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
> CC to matplotlib-devel & matplotlib-users
> 
> 2010年9月3日 Tony S Yu <ts...@gm...>:
>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>> 
>>> Hello,
>>> 
>>> While using sage [1], I got problems drawing a line: for some reason,
>>> the points with negative coordinates are not plotted (or are plotted
>>> on top of others due to an offset problem and thus I cannot see them).
>>> I can only reproduce the bug with specific data sets.
>>> 
>>> [1] www.sagemath.org
>>> 
>>> I think I could track down the bug to matplotlib, which sage uses to
>>> render 2d plots.
>>> 
>>> I included a sage script which generates the data set (in a pickle
>>> file), and a python script which draws the faulty line.
>>> 
>>> Usage is :
>>> 
>>> $ sage generate_data.sage
>>> $ python test_mpl.py
>>> 
>>> I also included the pickled data, thus you don't need sage at all.
>>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>> 
>>> Could somebody here confirm the problem, and give me a hint about what
>>> is going on?
>> 
>> I can confirm the issue.
> 
> Great, thank you. I filed a bug:
> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
> 
>> This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
>> 
>> The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
>> 
>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
>> 
>> I don't really know how to debug drawing errors like this; so this is as far as can get.
I'm not sure if I should respond to this email or the bug report, but since I made the claim here, I'll correct myself here: The bug is not in the drawing code as I had suggested. 
The bug is related to path simplification. If you turn off path simplification (e.g. plt.rc('path', simplify=False), the line is drawn in its entirety. This also explains why the bug disappeared when I trimmed the first two points: path simplification is triggered from data sets with atleast 128 points (your data has 129, so trimming two points turned off path simplification).
I just wanted to correct my earlier comments.
-T

On 08/31/2010 01:08 AM, Jens Nie wrote:
> Hi everyone.
> I face a problem here, which I can’t seem to handle by myself, so any
> help is really appreciated.
> I would like to do a simple line plot of a huge dataset as an overview
> to quickly compare success of different measurement scenarios, and it
> seems that not every datapoint is displayed. I played a little with the
> lod parameter, both for the creation of the axis and the plot command.
> However timing the plot command and the display itself do not show
> differences. Here are a few lines of code that help to reproduce the
> problem.
Jens,
I'm confident this is the same bug as was reported more recently on the 
list and the tracker:
https://sourceforge.net/tracker/index.php?func=detail&aid=3058804&group_id=80706&atid=560720
That report will make it easier to debug because it illustrates the 
problem with a relatively few points.
Eric
> import time
> import matplotlib
> matplotlib.use("Qt4Agg")
> import matplotlib.pyplot as plt
> import numpy as np
> xData=np.linspace(0, 10.0, 1e6)
> yData=np.zeros(xData.shape)
> xDataDetail=np.linspace(0.0, 2*np.pi, 1000)
> yDataDetail=np.exp(-xDataDetail)*np.sin(10.0*xDataDetail)
> yData[100000:100000+len(yDataDetail)]=yDataDetail
> fig=plt.figure()
> axes=fig.add_subplot(111)
> tic=time.time()
> axes.plot(xData, yData, "b-")
> toc=time.time()
> axes.grid(True)
> print "Plotting took %g s." % (toc-tic)
> plt.show()
> The code shows how I usually use the matplotlib environment and creates
> a simple dataset of 1 million zeros with a short non trivial peak
> within, that is to be plotted as a blue solid line.
> You can see what happens, when you vary the width of the displaying
> window. On my system usually the minimum amplitude varies when resizing
> the window.
> Is there any way to enforce plotting each and every point?
> I use matplotlib version 1.0.0 on a 32 Bit windows XP system installed
> via the windows installer from sf.
> A quick check on a opensuse 11.3 linux box showed the same issue. Using
> the "standard" TK backend instead of Qt4Agg behaves just the same.
> Jens
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

CC to matplotlib-devel & matplotlib-users
2010年9月3日 Tony S Yu <ts...@gm...>:
> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>
>> Hello,
>>
>> While using sage [1], I got problems drawing a line: for some reason,
>> the points with negative coordinates are not plotted (or are plotted
>> on top of others due to an offset problem and thus I cannot see them).
>> I can only reproduce the bug with specific data sets.
>>
>> [1] www.sagemath.org
>>
>> I think I could track down the bug to matplotlib, which sage uses to
>> render 2d plots.
>>
>> I included a sage script which generates the data set (in a pickle
>> file), and a python script which draws the faulty line.
>>
>> Usage is :
>>
>> $ sage generate_data.sage
>> $ python test_mpl.py
>>
>> I also included the pickled data, thus you don't need sage at all.
>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>
>> Could somebody here confirm the problem, and give me a hint about what
>> is going on?
>
> I can confirm the issue.
Great, thank you. I filed a bug:
https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
> This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
>
> The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
>
> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
>
> I don't really know how to debug drawing errors like this; so this is as far as can get.

Hi,
I am plotting several different symbols using 3 different colours. The
colours indicate different data sets, whereas the symbols need not be
explained. I would therefore like each label to have a different colour,
i.e. each line in my legend should be written in a different colour
specified. The legend is getting too long if I have to indicate what each
symbol represents, plus it would be a repetition of the 3 data sets in
question. How can I change the colour of the text in the legend?
Second, how can I change the marker in the legend? I am plotting using
errorbar(), but the marker shows up as a dot, and I would like it to show up
as a '+', without having to change the actual dots in the plot.
Here is a snippet of my code:
import matplotlib as mpl
import matplotlib.pyplot as plt
fig = plt.figure(); ax = []
for k in range(1,4):
 ax.append(fig.add_subplot(3,1,k))
 for [data,col,leg] in
[[data1,'k','set1'],[data2,'r','set2'],[data3,'b','both']]:
 
ax[-1].errorbar(data[:,2],data[:,4],xerr=data[:,3],yerr=data[:,5],fmt='.',color=col,label=leg)
 ax[-1].plot(x,y,'-',color=col,label=leg)
 lgd=ax[-1].legend(loc='lower right')
 #this is what I tried to change the symbols in the legend, but it
also changes the plot
 #symbols and I would like to avoid that:
 plt.setp(lgd.get_lines(), marker='+')
I have searched this forum, other forums, and google, without finding an
answer to my questions. If there is another post or webpage already dealing
with these problems I apologise for posting them here too and ask you to
please direct me to the right pages.
Cheers, Karianne
-- 
View this message in context: http://old.nabble.com/legend%3A-changing-the-text-colour-tp29614647p29614647.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
> Hello,
> 
> While using sage [1], I got problems drawing a line: for some reason,
> the points with negative coordinates are not plotted (or are plotted
> on top of others due to an offset problem and thus I cannot see them).
> I can only reproduce the bug with specific data sets.
> 
> I think I could track down the bug to matplotlib, which sage uses to
> render 2d plots.
> 
> I included a sage script which generates the data set (in a pickle
> file), and a python script which draws the faulty line.
> 
> Usage is :
> 
> $ sage generate_data.sage
> $ python test_mpl.py
> 
> I also included the pickled data, thus you don't need sage at all.
> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
> 
> Could somebody here confirm the problem, and give me a hint about what
> is going on?
I can confirm the issue. This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
I don't really know how to debug drawing errors like this; so this is as far as can get.
Best,
-Tony
> 
> Regards
> Sebastien
> 
> [1] www.sagemath.org
> <generate_data.sage><test_mpl.py><traj_mod.pickle>

Hello,
While using sage [1], I got problems drawing a line: for some reason,
the points with negative coordinates are not plotted (or are plotted
on top of others due to an offset problem and thus I cannot see them).
I can only reproduce the bug with specific data sets.
I think I could track down the bug to matplotlib, which sage uses to
render 2d plots.
I included a sage script which generates the data set (in a pickle
file), and a python script which draws the faulty line.
Usage is :
$ sage generate_data.sage
$ python test_mpl.py
I also included the pickled data, thus you don't need sage at all.
I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
Could somebody here confirm the problem, and give me a hint about what
is going on?
Regards
Sebastien
[1] www.sagemath.org

On 09/02/2010 07:47 PM, Noam Yorav-Raphael wrote:
> Hello,
>
> I'm the developer of DreamPie, a new graphical Python shell (you can
> check it out at http://dreampie.sourceforge.net )
>
> I worked to make it work nicely with matplotlib -- it runs Tk/GTK/Qt
> event loops when idle, so if matplotlib is in interactive mode it
> works great. I even made DreamPie check if matplotlib in
> non-interactive mode is present, and if so it shows you a message
> suggesting that you switch to interactive mode.
>
> Lately I thought that it may be much easier for users if DreamPie
> would just switch matplotlib to interactive mode automatically.
> However, I'm not entirely comfortable with the idea of changing
> settings silently.
>
> I wanted to ask: what do you think? Are there any cases when you want
> to have matplotlib in non-interactive mode in a shell?
At least with ipython, yes--the point of non-interactive mode is that 
the show() function blocks, so it can be used in scripts in which the 
user is supposed to see a plot, dismiss the window, see another plot, 
etc. Again, at least with ipython, one wants to be *able* to run scripts 
exactly as they would run from the command line.
Whether this sort of thing matters for DreamPie depends on the intended 
uses and users.
Eric
>
> Also, are there any other ways in which DreamPie can be made more
> matplotlib-friendly?
>
> Thanks,
> Noam
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello,
I'm the developer of DreamPie, a new graphical Python shell (you can
check it out at http://dreampie.sourceforge.net )
I worked to make it work nicely with matplotlib -- it runs Tk/GTK/Qt
event loops when idle, so if matplotlib is in interactive mode it
works great. I even made DreamPie check if matplotlib in
non-interactive mode is present, and if so it shows you a message
suggesting that you switch to interactive mode.
Lately I thought that it may be much easier for users if DreamPie
would just switch matplotlib to interactive mode automatically.
However, I'm not entirely comfortable with the idea of changing
settings silently.
I wanted to ask: what do you think? Are there any cases when you want
to have matplotlib in non-interactive mode in a shell?
Also, are there any other ways in which DreamPie can be made more
matplotlib-friendly?
Thanks,
Noam

Hello, list!
I am trying to create a Mac application package from python modules using
matplotlib and wxpython.
Before packaging, my code generated only a user warning of multiple calls on
matplotlib.use method.
When I tried to run the application after packaging with py2app, the
application crashed with the following error message:
....
app/Contents/Resources/lib/python2.6/matplotlib/backends/backend_wx.py line
1769 in _init_toolbar ..
app/Contents/Resources/lib/python2.6/matplotlib/backends/backend_wx.py line
1609 in _load_bitmap ..
app/Contents/Resources/lib/python2.6/wx/_gdi.py line 555 in __init__ ..
PyAssertionError: C++ assertion "IsOpened()" failed at
/BUILD/wxPython-src-2.8.11.0/src/common/ffile.cpp(175)
in Seek(): can't seek on closed file
Please let me know how I can solve this problem.
Thanks in advance!
from Myunghwa Hwang
-- 
Myunghwa Hwang
GeoDa Center
School of Geographical Sciences and Urban Planning
Arizona State University
mh...@gm... or Myu...@as...

From: Yi Shang [mailto:mir...@gm...] 
Sent: Friday, August 27, 2010 15:34
from numpy import *
from matplotlib import pyplot as plt
import pylab
params = {'font.size' : 16,
 'axes.labelsize' : 16,
 'font.style' : 'normal',
 'font.family' : 'sans-serif',
 'font.sans-serif' : 'Arial'
}
pylab.rcParams.update(params)
By the way, the update() method above bypasses the validation [1] provided by
the RcParams class. Thus you must take care to give a list of font names for
font.sans-serif and other font families. If you use
for (k, v) in {'font.sans-serif': 'Arial'}.items():
 plt.rcParams[k] = v
or
plt.rc('font', **{'sans-serif': 'Arial'})
then your parameters will be validated, a process that automatically encloses
into a list font names given for families.
[1]
http://matplotlib.sourceforge.net/users/customizing.html#dynamic-rc-settings

On Thu, Sep 2, 2010 at 9:23 AM, Benjamin Root <ben...@ou...> wrote:
> This also raises another pet peeve of mine. The Agg backend seems to use
> linear blending for alpha. This is inconsistent with how the world works.
> It is more realistic for logarithmic blending, or at least, a piece-wise
> linear blending.
>
> Imagine I have two overlapping objects with alpha set to .5 (a_1 and a_2).
> What is rendered in matplotlib is completely opaque. A more realistic
> result would have a final alpha setting of .75 (i.e. - the first item takes
> away half the transparency, then the second item takes away half of the
> remaining transparency.
>
> I am not nearly familiar enough with the Agg backend to know how to
> implement this. Is this at all feasible?
I'm not sure this is what's going on. Right now, though, I'm seeing
some weird draw artifacts that I don't have time to run down. What I
will say is that while some other blending functions may be
interesting, I don't think it's widely supported. OpenGL just treats
the alpha as a weight for the colors. You can tweak it, but it's
inherently linear unless you write a pixel shader.
Also, I don't think the blending produces an opaque result. I'm pretty
sure you can blend 3 colors together, each with an alpha > 0.5. The
color will be pretty saturated, but opaque would mean the bottom color
doesn't show through. (I'll hack on an example later). Remember,
though, that your monitor doesn't display an "alpha" color. Any
translucency from a net blending of colors just means that you're
blending in a background color (alpha=1.0) somewhere.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Sep 2, 2010 at 9:11 AM, Ryan May <rm...@gm...> wrote:
> On Thu, Sep 2, 2010 at 2:15 AM, Mitesh Patel <qe...@gm...> wrote:
> > Hello,
> >
> > Is it possible to specify both an alpha level and a background color so
> > that an entire saved image has a uniform transparency and color? For
> > example, with matplotlib 1.0.0, this script yields the attached image:
> >
> > from matplotlib.pyplot import figure, savefig, show
> >
> > fig = figure()
> > ax = fig.add_subplot(111)
> > ax.plot([1,2,3])
> >
> > fig.patch.set_alpha(0.5)
> > for ax in fig.axes:
> > ax.patch.set_alpha(0.5)
> >
> > fig.patch.set_facecolor('red')
> > for ax in fig.axes:
> > ax.patch.set_facecolor('red')
> >
> > savefig('test.png', facecolor='red')
> >
> >
> > In particular, the areas inside and outside the axes have different
> > transparency level and color. Perhaps I'm over/mis/ab-using the options
> > here?
>
> It's not that they're not uniform--you're seeing alpha blending
> between the figure patch and the axes patch. Within the axes, both are
> being rendered and blended together. This is more readily apparent if
> you use blue for the axes patch, as I did for the attached image. When
> the red and blue are blended together, you end up with purple. If you
> want it all uniform, you'd be better off setting the axes patch to an
> alpha of 0.0.
>
> Ryan
>
>
This also raises another pet peeve of mine. The Agg backend seems to use
linear blending for alpha. This is inconsistent with how the world works.
It is more realistic for logarithmic blending, or at least, a piece-wise
linear blending.
Imagine I have two overlapping objects with alpha set to .5 (a_1 and a_2).
What is rendered in matplotlib is completely opaque. A more realistic
result would have a final alpha setting of .75 (i.e. - the first item takes
away half the transparency, then the second item takes away half of the
remaining transparency.
I am not nearly familiar enough with the Agg backend to know how to
implement this. Is this at all feasible?
Ben Root

On Thu, Sep 2, 2010 at 2:15 AM, Mitesh Patel <qe...@gm...> wrote:
> Hello,
>
> Is it possible to specify both an alpha level and a background color so
> that an entire saved image has a uniform transparency and color? For
> example, with matplotlib 1.0.0, this script yields the attached image:
>
> from matplotlib.pyplot import figure, savefig, show
>
> fig = figure()
> ax = fig.add_subplot(111)
> ax.plot([1,2,3])
>
> fig.patch.set_alpha(0.5)
> for ax in fig.axes:
> ax.patch.set_alpha(0.5)
>
> fig.patch.set_facecolor('red')
> for ax in fig.axes:
> ax.patch.set_facecolor('red')
>
> savefig('test.png', facecolor='red')
>
>
> In particular, the areas inside and outside the axes have different
> transparency level and color. Perhaps I'm over/mis/ab-using the options
> here?
>
> Thanks for your great software and any help you can provide!
>
> Sincerely,
> Mitesh Patel
>
>
>
Mitesh,
That is an interesting idea. Theoretically, it might be possible to
implement such a feature. The key design idea of Matplotlib is to have
Artist objects that own other Artist objects. So, a Figure owns several
axes, and those axes own various plotting elements, which are all subclasses
of Artists. So, I could imagine that an rgba value could get "inherited" by
a child artist from its parent (unless the user specifies differently).
Would we want to automatically make text inherit the rgba setting? Also,
currently there are a lot of places in code where one directly specifies
color, or color is automatically chosen (from a colormap or a rotating set
of colors). I wonder what should be the proper behavior in those cases
(ignore parent setting? if so, then do the setting still get passed on to
child artists? should the automatically chosen settings get passed on?).
What do others think?
Ben Root

On Thu, Sep 2, 2010 at 2:15 AM, Mitesh Patel <qe...@gm...> wrote:
> Hello,
>
> Is it possible to specify both an alpha level and a background color so
> that an entire saved image has a uniform transparency and color? For
> example, with matplotlib 1.0.0, this script yields the attached image:
>
> from matplotlib.pyplot import figure, savefig, show
>
> fig = figure()
> ax = fig.add_subplot(111)
> ax.plot([1,2,3])
>
> fig.patch.set_alpha(0.5)
> for ax in fig.axes:
>  ax.patch.set_alpha(0.5)
>
> fig.patch.set_facecolor('red')
> for ax in fig.axes:
>  ax.patch.set_facecolor('red')
>
> savefig('test.png', facecolor='red')
>
>
> In particular, the areas inside and outside the axes have different
> transparency level and color. Perhaps I'm over/mis/ab-using the options
> here?
It's not that they're not uniform--you're seeing alpha blending
between the figure patch and the axes patch. Within the axes, both are
being rendered and blended together. This is more readily apparent if
you use blue for the axes patch, as I did for the attached image. When
the red and blue are blended together, you end up with purple. If you
want it all uniform, you'd be better off setting the axes patch to an
alpha of 0.0.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi, I was struggling with the same problem since 2 days. But today I found
the solution here:
http://efreedom.com/Question/1-2195983/Matplotlib-Formatting-Dates-Axis-3D-Bar-Graph
#When you use the method 
ax.set_xtics
#it doesn't put ticks to your 3d plot, instead puts ticst to 2D canvas. 
#When you use Axes3D, I understand that you should use:
ax.w_xaxis
ax.w_yaxis
ax.w_zaxis 
#to set axis properties. However if you try:
ax.w_xaxis.set_ticks(arrayOfTicks)
#screws up the plot. Instead you can use this, which worked perfect with
matplotlib 1.0 for me.
import matplotlib.ticker as ticker
ax.w_xaxic.set_major_locator(ticker.FixedLocator(arrayOfTicks))
Cheers
Cenk
Mark B. wrote:
> 
> Hello list, I am trying to set ticks on an Axes3D plot.
> What I really want is, actually, not to have any ticks.
> For a 2D plot I set the ticks to an empty list.
> But in a 3D plot, I cannot set any ticks whatsover.
> At least not with a sequence.
> Any thoughts?
> 
> from mpl_toolkits.mplot3d import Axes3D
> 
> fig = figure()
> 
> ax = Axes3D(fig)
> 
> ax.plot([0,1],[0,1],[0,1])
> 
> # Now I want to set ticks:
> 
> ax.set_xticks([])
> 
> # ax.set_xticks([.2,.3,.4]) # changes the scale of the figure, but not the
> ticks
> 
> show()
> 
> And the plot has ticks at .2 .4 .6 .8 on the x-axis.
> 
> Thanks for any help,
> 
> Mark
> 
> 
-- 
View this message in context: http://old.nabble.com/setting-ticks-on-Axes3D-tp27012587p29601789.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Benjamin Root <ben.root@...> writes:
> 
> Jens,Which version of matplotlib are you using? I wonder if this is the 
> path.simplify bug that was fixed for 1.0.Essentially, there was a bug in some 
> code that caused some points to be skipped in the process of displaying images 
> that had datapoints that were closer together than could be resolved. I 
> suspect this is what is happening here, because everything looks fine on my 
> latest build.
> Ben Root
Hello Ben,
I have the same problem here (mpl on windows, with the tk-agg backend). After
reading your comment above, I upgraded to 1.0.0, which improved the situation:
In Jens' example code, the old version (I think it was 0.99.1?) had problems
with both the high and the low peak (which could be seen when horizontally
resizing the window); in version 1.0 the high peak is shown correctly (y=0.86),
while the low peak shows "random" values instead of the real minimum (y=-0.63).
In my environment, path.simplify is True. When I set it to False, the problem
disappears, however plotting gets (too) slow for my large data sets. And it
should work correctly with path.simplify, right?
Thanks in advance for your assistance,
Hans

Mike,
Using svn trunk, I see exactly the problem Jens is talking about. Maybe 
there is still a bug in the path simplification? If I try to plot after 
turning simplification off, I don't get any image at all, so I can't 
immediately say whether the problem is in the simplification.
To reproduce the bug, run the example Jens supplied, and try changing 
the window width a few times.
Eric
On 08/31/2010 01:08 AM, Jens Nie wrote:
> Hi everyone.
> I face a problem here, which I can’t seem to handle by myself, so any
> help is really appreciated.
> I would like to do a simple line plot of a huge dataset as an overview
> to quickly compare success of different measurement scenarios, and it
> seems that not every datapoint is displayed. I played a little with the
> lod parameter, both for the creation of the axis and the plot command.
> However timing the plot command and the display itself do not show
> differences. Here are a few lines of code that help to reproduce the
> problem.
> import time
> import matplotlib
> matplotlib.use("Qt4Agg")
> import matplotlib.pyplot as plt
> import numpy as np
> xData=np.linspace(0, 10.0, 1e6)
> yData=np.zeros(xData.shape)
> xDataDetail=np.linspace(0.0, 2*np.pi, 1000)
> yDataDetail=np.exp(-xDataDetail)*np.sin(10.0*xDataDetail)
> yData[100000:100000+len(yDataDetail)]=yDataDetail
> fig=plt.figure()
> axes=fig.add_subplot(111)
> tic=time.time()
> axes.plot(xData, yData, "b-")
> toc=time.time()
> axes.grid(True)
> print "Plotting took %g s." % (toc-tic)
> plt.show()
> The code shows how I usually use the matplotlib environment and creates
> a simple dataset of 1 million zeros with a short non trivial peak
> within, that is to be plotted as a blue solid line.
> You can see what happens, when you vary the width of the displaying
> window. On my system usually the minimum amplitude varies when resizing
> the window.
> Is there any way to enforce plotting each and every point?
> I use matplotlib version 1.0.0 on a 32 Bit windows XP system installed
> via the windows installer from sf.
> A quick check on a opensuse 11.3 linux box showed the same issue. Using
> the "standard" TK backend instead of Qt4Agg behaves just the same.
> Jens
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users