matplotlib-users Mailing List for matplotlib (Page 6)

[snip]
> Are you aware that the plot method can plot the columns of=20
> 2-D arrays?=20
> Any kwargs apply to all the lines. When plot does this, it=20
> makes a list of lines, not a line collection, so it is=20
> similar to looping over a set of single plot commands. There=20
> is no particular speed advantage, but it is nice and concise,=20
> if it yields what you actually want.
Interesting! No, I wasn't aware. I'll need to think a bit if that fits
better into the framework we have here.
Thanks for the input.
Anthony.

Anthony M. Floyd wrote:
>> -----Original Message-----
>> From: Eric Firing [mailto:ef...@ha...] 
> 
> [snip]
> 
>> It probably comes down to program simplicity and readability, 
>> not speed, in your case.
>>
>> Eric
> 
> 
> Hi Eric,
> 
> Thanks for this. That's essentially the decision I had reached, but I
> was also wondering if I'd missed something significant. I think I will
> code it up as-is right now, and if the routine is unacceptably slow
> re-examine it with an eye to shifting over to using line-collections.
> 
> In the same vein, if I need to refactor, is there any benefit to
> treating single series as a collection with only one segment? I would
> rather treat single series and multiple series in the same manner --
> either plotting single series and multiple single-series or plotting
> single-series collections and multiple-series collections. That is, I'd
> rather not have to treat plotting a single series in one manner and
> multiple series in another.
A collection with only one member should work fine, although I don't 
know whether it has been explicitly tested. So, I don't see any reason 
why you should have to treat a single series as a special case.
Are you aware that the plot method can plot the columns of 2-D arrays? 
Any kwargs apply to all the lines. When plot does this, it makes a list 
of lines, not a line collection, so it is similar to looping over a set 
of single plot commands. There is no particular speed advantage, but it 
is nice and concise, if it yields what you actually want.
Eric
> 
> Thanks,
> Anthony. 
> 
> 

> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...]=20
[snip]
> It probably comes down to program simplicity and readability,=20
> not speed, in your case.
>=20
> Eric
Hi Eric,
Thanks for this. That's essentially the decision I had reached, but I
was also wondering if I'd missed something significant. I think I will
code it up as-is right now, and if the routine is unacceptably slow
re-examine it with an eye to shifting over to using line-collections.
In the same vein, if I need to refactor, is there any benefit to
treating single series as a collection with only one segment? I would
rather treat single series and multiple series in the same manner --
either plotting single series and multiple single-series or plotting
single-series collections and multiple-series collections. That is, I'd
rather not have to treat plotting a single series in one manner and
multiple series in another.
Thanks,
Anthony.=20

Anthony,
When I do a quick test of line_collection.py versus a modification that 
makes individual plot calls, with the results written to a png file, I 
get about 1.05 s with the collection and 1.2 s with the lines. But a 
trivial plot still takes 0.52 seconds, so if you subtract out this 
general startup overhead the improvement with the line collection is 
about 30%.
It probably comes down to program simplicity and readability, not speed, 
in your case.
Eric
Anthony M. Floyd wrote:
> I'm trying to figure out the best way to handle the following situation:
> I have a wxApp that embeds a matplotlib figure in a panel. I use custom
> code to control adding and removing series from the axes in this figure,
> with some pretty fine grained control on when things get drawn, zoomed,
> etc. To be clear, I'm not using pylab here, I'm coding directly into
> matplotlib.
> 
> Anyhow, I now have the case where I want to be plotting a modest number
> of series (say 100) with a reasonably large density (say >1000 pts).
> These series will all have the same or similar styles (thickness,
> colour, etc) and will definitely have the same length.
> 
> In context of my current app, I could achieve this simply by calling my
> .addSeries routine multiple times. Or, I could use a Line Collection to
> handle them en masse.
> 
> The thing is, after taking a quick read through of the source code, I'm
> not certain that I'm gaining anything by using a line collection in this
> case. 
> 
> I did a quick comparison using the line_collection.py example, and even
> using pylab there didn't seem to be any performance hit to doing:
> 
> lines = [zip(x,y) for y in ys]
> for series in x:
> 	plot(lines[series])
> 
> Instead of using:
> 
> line_segments = ...
> ax.add_collection(line_segments)
> 
> Can anyone give me advice if I should code targeting collections or to
> just use my current single-series code?
> 
> Thanks,
> Anthony.
> 
> 
> 
> --
> Anthony Floyd, PhD
> Convergent Manufacturing Technologies Inc.
> 6190 Agronomy Rd, Suite 403
> Vancouver BC V6T 1Z3
> CANADA
> 
> Email: Ant...@co... | Tel: 604-822-9682
> WWW: http://www.convergent.ca | Fax: 604-822-9659 
> 
> CMT is hiring: See http://www.convergent.ca for details
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I'm trying to figure out the best way to handle the following situation:
I have a wxApp that embeds a matplotlib figure in a panel. I use custom
code to control adding and removing series from the axes in this figure,
with some pretty fine grained control on when things get drawn, zoomed,
etc. To be clear, I'm not using pylab here, I'm coding directly into
matplotlib.
Anyhow, I now have the case where I want to be plotting a modest number
of series (say 100) with a reasonably large density (say >1000 pts).
These series will all have the same or similar styles (thickness,
colour, etc) and will definitely have the same length.
In context of my current app, I could achieve this simply by calling my
.addSeries routine multiple times. Or, I could use a Line Collection to
handle them en masse.
The thing is, after taking a quick read through of the source code, I'm
not certain that I'm gaining anything by using a line collection in this
case. =20
I did a quick comparison using the line_collection.py example, and even
using pylab there didn't seem to be any performance hit to doing:
lines =3D [zip(x,y) for y in ys]
for series in x:
	plot(lines[series])
Instead of using:
line_segments =3D ...
ax.add_collection(line_segments)
Can anyone give me advice if I should code targeting collections or to
just use my current single-series code?
Thanks,
Anthony.
--
Anthony Floyd, PhD
Convergent Manufacturing Technologies Inc.
6190 Agronomy Rd, Suite 403
Vancouver BC V6T 1Z3
CANADA
Email: Ant...@co... | Tel: 604-822-9682
WWW: http://www.convergent.ca | Fax: 604-822-9659 =20
CMT is hiring: See http://www.convergent.ca for details

That did it.
thanks!
Eric Firing wrote:
> Johann Cohen-Tanugi wrote:
>> hello,
>> I am using matplotlib to make a drawing, so though I am using 
>> distances on the pad I do not need to display the axes and would 
>> rather have no frame and no tick.
>> To achieve this, I tried using :
>> rc('axes', edgecolor='white')
>
> If your axes instance is "ax", try
> ax.set_frame_on(False)
> ax.set_axis_off()
>
> The api is inconsistent, but there it is...
>
> This will actually wipe out the axes patch as well as the boundary, 
> and all traces of the axes; maybe this is more than you want.
>
> Eric
>
>> rc('xtick', color='white')
>> rc('ytick', color='white')
>>
>> The first command works, but not the 2 tick commands (the ticks still 
>> show up, in black)...... Bug or feature? Besides, I am sure there is 
>> a better way to do that, but could not find out.
>> I am using the GTKAgg backend.
>>
>> thanks,
>> Johann
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Johann Cohen-Tanugi wrote:
> hello,
> I am using matplotlib to make a drawing, so though I am using distances 
> on the pad I do not need to display the axes and would rather have no 
> frame and no tick.
> To achieve this, I tried using :
> rc('axes', edgecolor='white')
If your axes instance is "ax", try
 ax.set_frame_on(False)
 ax.set_axis_off()
The api is inconsistent, but there it is...
This will actually wipe out the axes patch as well as the boundary, and 
all traces of the axes; maybe this is more than you want.
Eric
> rc('xtick', color='white')
> rc('ytick', color='white')
> 
> The first command works, but not the 2 tick commands (the ticks still 
> show up, in black)...... Bug or feature? Besides, I am sure there is a 
> better way to do that, but could not find out.
> I am using the GTKAgg backend.
> 
> thanks,
> Johann
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 20/08/07, Darren Dale <dd...@co...> wrote:
> On Monday 20 August 2007 12:11:30 pm Samuel M.Smith wrote:
> > I can only generate .eps files that will successfully distill
> > into .pdf files when I use
> >
> > ps.usedistiller : xpdf
> > not
> > ps.usedistiller : ghostscript
> > nor
> > ps.usedistiller : None
> >
> > Is this a known problem?
> > ghostscript does work fine for .ps files just not .eps
>
> No, it is not a known problem. I have never had a problem converting an eps to
> pdf, using either setting. Are you using epstopdf? Could you post an example,
> something that actually illustrates a problem?
>
> > In addition when ever I save a .eps file I get the following error
> > even though it creates the file ok
> >
> > : Error: No paper information available - using defaults
> >
> > %%BoundingBox: 78 220 543 561
> > %%HiResBoundingBox: 78.281998 220.589993 542.375983 560.357983
> >
> > Is there a way to fix this?
>
> Is this with verbose.level set to silent?
Interestingly I just installed ubuntu gutsy AMD64 on my machine (yes I
know it's alpha) and found that I get a strangely similar problem
(with subversion matplotlib). But only if i use *xpdf* as the
distiller, not ghostscript. I also get the same error with the
bounding box / no paper information. I put it down to ubuntu alpha
status rather than matplotlib which is why I didn't report it, but
this has made me think possibly otherwise?? I'll send more details if
you're interested.
John

On 2007年8月20日, Johann Cohen-Tanugi apparently wrote:
> I am sure there is a 
> better way to do that 
Set the ticks to an empty tuple.
hth,
Alan Isaac

hello,
I am using matplotlib to make a drawing, so though I am using distances 
on the pad I do not need to display the axes and would rather have no 
frame and no tick.
To achieve this, I tried using :
rc('axes', edgecolor='white')
rc('xtick', color='white')
rc('ytick', color='white')
The first command works, but not the 2 tick commands (the ticks still 
show up, in black)...... Bug or feature? Besides, I am sure there is a 
better way to do that, but could not find out.
I am using the GTKAgg backend.
thanks,
Johann

On Monday 20 August 2007 12:11:30 pm Samuel M.Smith wrote:
> I can only generate .eps files that will successfully distill
> into .pdf files when I use
>
> ps.usedistiller : xpdf
> not
> ps.usedistiller : ghostscript
> nor
> ps.usedistiller : None
>
> Is this a known problem?
> ghostscript does work fine for .ps files just not .eps
No, it is not a known problem. I have never had a problem converting an eps to 
pdf, using either setting. Are you using epstopdf? Could you post an example, 
something that actually illustrates a problem? 
> In addition when ever I save a .eps file I get the following error
> even though it creates the file ok
>
> : Error: No paper information available - using defaults
>
> %%BoundingBox: 78 220 543 561
> %%HiResBoundingBox: 78.281998 220.589993 542.375983 560.357983
>
> Is there a way to fix this?
Is this with verbose.level set to silent?

I can only generate .eps files that will successfully distill 
into .pdf files when I use
ps.usedistiller : xpdf
not
ps.usedistiller : ghostscript
nor
 ps.usedistiller : None
Is this a known problem?
ghostscript does work fine for .ps files just not .eps
In addition when ever I save a .eps file I get the following error 
even though it creates the file ok
: Error: No paper information available - using defaults
%%BoundingBox: 78 220 543 561
%%HiResBoundingBox: 78.281998 220.589993 542.375983 560.357983
Is there a way to fix this?
I have
ps.papersize : letter
my configuration
Mac OS X 10.4.10 PPC
python 2.5.1
Matplotlib 0.90.1
ipython 0.8.1
wxPython2.8-osx-unicode-2.8.3.0-universal10.4-py2.5
ghostscript 8.54
xpdf 3.02
**********************************************************************
Samuel M. Smith Ph.D.
2966 Fort Hill Road
Eagle Mountain, Utah 84005-4108
801-768-2768 voice
801-768-2769 fax
**********************************************************************
"The greatest source of failure and unhappiness in the world is
giving up what we want most for what we want at the moment"
**********************************************************************

Hi,
 I am trying to plot a graph as shown.
http://trac-hacks.org/attachment/wiki/TracMetrixDashboard/cummulative.PNG
 I am not sure why the label start at the point 1 instead of point 0. Here
is the code that is used to generate the graph.
matplotlib.use(*'Agg'*)
fig = figure()
ax = fig.add_subplot(111) # Create supplot with key 111
ax.cla()
ax.plot(numdates, tkt_cummulative_table[*'Enter'*], *'b-'*)
ax.plot(numdates, tkt_cummulative_table[*'Leave'*], *'r-'*)
ax.plot(numdates, tkt_cummulative_table[*'Finish'*], *'g-'*)
ax.set_xlim( numdates[0], numdates[-1] )
ax.xaxis.set_major_locator(DayLocator())
ax.xaxis.set_major_formatter( DateFormatter(*'%Y-%m-%d'*))
ax.fmt_xdata = DateFormatter(*'%Y-%m-%d %H:%M:%S'*)
labels = ax.get_xticklabels()
setp(labels, rotation=45, fontsize=8)
xlabel(*'Dates (day)'*)
ylabel(*'Counts (times)'*)
title(*'Cummulative flow chart for ticket status history'*)
legend((*'Ticket Entered'*, *'Ticket Left'*, *'Ticket Completed'*), loc=*'upper
left'*)
 numdate is the array of date generated from drange function. I am pretty
new to matplotlib. I create these code from looking at the examples. I
might have done something wrong. If you could put it out for me, it would
be very appreciated.
 I am also wonder why we need ax.set_xlim( numdates[0], numdates[-1]. However,
if I don't use it. There graph will include a few days that aren't in the
numdates in the graph.
Thanks,
Deen

Deen Sethanandha wrote:
> Hello,
> 
> I am trying to plot 2 bar charts in the same plane like the one in 
> sourceforge. 
> http://sourceforge.net/project/stats/detail.php?group_id=5470&ugn=python&mode=week&type=tracker 
> <http://sourceforge.net/project/stats/detail.php?group_id=5470&ugn=python&mode=week&type=tracker>
> 
> It would be great to be able to plot like that or 2 bars with 2 colors.
> 
> Thanks,
> Deen
Deen: See table_demo.py at
http://matplotlib.sourceforge.net/screenshots.html
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Hello,
 I am trying to plot 2 bar charts in the same plane like the one in
sourceforge.
http://sourceforge.net/project/stats/detail.php?group_id=5470&ugn=python&mode=week&type=tracker
 It would be great to be able to plot like that or 2 bars with 2 colors.
Thanks,
Deen

Daniel Fish wrote:
> In response to revision number 3641 (bar plotting patch by Michael 
> Forbes (link below): Inside axes.py, the function 'hlines' is missing 
> the line "coll.update(kwargs)" found in the analogous function 'vlines', 
> so the horizontal linewidth kwarg does not update.
Thank you. It is now fixed in 3715.
Eric

Hi,
What's the equivalent command in matplotlib to matlab's "surf"? I
assume it's Axes3D.plot_surface. But this doesn't see to work. The
code to be ported is:
s = surf(linspace(0,2,100), linspace(-1,1,100), fe');
But in matplotlib I've come up with:
terrain = R.randn(100, 100) / 1
nbumps = 20
f = lambda x: [int(v) for v in x]
bumpsx = 100 * R.rand(1, nbumps)
bumpsx = map(f, bumpsx.round())
bumpsy = 100 * R.rand(1, nbumps)
bumpsy = map(f, bumpsy.round())
f = lambda x: [abs(v) for v in x]
terrain[bumpsx, bumpsy] = map(f, abs(R.randn(1, nbumps))) # TODO:
abs(randn(nbumps, nbumps))
f = lambda x, y: I.lfilter((N.ones((1, x,)) / x)[0], 1, y)
fterrain = (f(20, f(15, terrain).conj().T)).conj().T
x = N.linspace(0, 2, 100)
y = N.linspace(-1, 1, 100)
z = fterrain
surface = axes3d.plot_surface(x, y, z)
The problem is that x, y, and z all should have the same shape (or at
least I assume from the simple3d.py example). But in what's above, x
and y have a shape of (100,), and z has a shape of (100,100). What
should I do instead?
I'm more than happy to share all the source code if that would be
instructive. Thanks.
-Tom

hi Matthieu,
this will work too, with setp instead of set. Clearly 'set' is now 
reserved. Someone should update the user's guide.....
best,
Johann
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 2007年8月16日 18:27:33 +0200
> From: "Matthieu Brucher" <mat...@gm...>
> Subject: Re: [Matplotlib-users] problem with set in current svn HEAD
> To: Mat...@li...
> Message-ID:
> 	<e76...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I think you must type :
> set(gca(), 'xticklabels', [])
>
> Matthieu
>
> 

In response to revision number 3641 (bar plotting patch by Michael =
Forbes (link below): Inside axes.py, the function 'hlines' is missing =
the line "coll.update(kwargs)" found in the analogous function 'vlines', =
so the horizontal linewidth kwarg does not update.
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/=
lib/matplotlib/axes.py?view=3Dmarkup&pathrev=3D3641

Unfortunately, I think that is a known bug in 0.90.0. This is fixed in SVN, if you're able to use it.
Cheers,
Mike

I've been trying to install matplotlib with interactive plotting
support on a non-standard linux distribution (sidious.isani.org). I
have successfully installed matplotlib 0.90.1 with python 2.4.3 and
IPython 0.7.2. I can make plots with any of the image backends, but
the TkAgg backend fails with an "undefined symbol" error.
To install with TkAgg support I edited setup.py as follows:
BUILD_AGG = 1
BUILD_GTKAGG = 0
BUILD_GTK = 0
BUILD_TKAGG = 1
I run the build and install steps as root, getting no errors. If I
set the backend to Agg I can produce pdf or png plots just fine.
However, when I try to import the TkAgg backend, I get the following
error:
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/lib/python2.4/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 222, in ?
 new_figure_manager, draw_if_interactive, show = pylab_setup()
 File "/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py",
line 24, in pylab_setup
 globals(),locals(),[backend_name])
 File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py",
line 8, in ?
 import tkagg # Paint image to Tk photo blitter extension
 File "/usr/lib/python2.4/site-packages/matplotlib/backends/tkagg.py",
line 1, in ?
 import _tkagg
ImportError: /usr/lib/python2.4/site-packages/matplotlib/backends/_tkagg.so:
undefined symbol: XSetInputFocus
(I get the same error when testing as root or with my own user account)
This looks to me like a linker error. Maybe the xlib library is not
properly linked? I've checked that xsetinputfocus appears in
/usr/X11R7/include/X11/Xlib.h and I have added this directory to
setupext.py as:
basedir = {
 'win32' : ['win32_static',],
 'linux2' : ['/usr/local', '/usr','/usr/X11R7/include/X11',],
 'linux' : ['/usr/local', '/usr','/usr/X11R7/include/X11',],
Is there some other file I should be locating and linking, or some
other way to include xlib?
Thanks,
-steve

Hi again,
A related question: I tried to generate my PDF output with the Cairo
backend, which produces correct axis labels but no transparency. My
impression is that Cairo supports transparency, so is this a deficiency
in the backend? Or is there a trick?
Thanks again,
/Patrik

Hi all,
I've been making some plots with transparency and realized that in order
to get a vector output I have to use the PDF backend instead of PS.
However, the PDF plots have axis labels that are messed up. Instead of
showing "10^3" it shows "10_3", ie all exponents are subscripts, and the
axis numbers are at the top instead of the bottom, so they clobber the
graph title. There must be something not working right, because it's not
usable the way it is. Can anyone suggest fixes?
This is with 0.90.0 on a FC6 x86_64 machine.
Thanks,
/Patrik

Peter Würtz wrote:
> Hi,
> 
> Sorry this might look like a really stupid question, but I have not been
> able to find an answer in the matplotlib documentation...
Not a stupid question at all--it is more of a feature request.
> 
> When plotting data points using the "o"-style, some points are truncated
> by the axis borders. Is there a way to define some kind of margin
> without changing the x/y range manually?
No, this is something we probably should add. There are other cases 
also where one wants a margin by default.
> 
> So far, I did some kind of workaround:
> (xmin,xmax) = p.xlim()
> xw = xmax - xmin
> p.xlim(xmin - xw*0.05, xmax + xw*0.05)
> 
> Is there a better way than this?
No, it looks to me like you have found a reasonable workaround. One 
could also put this functionality into a custom Locator class, but that 
is more complicated.
Eric
> 
> Thanks,
> Peter
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,
Sorry this might look like a really stupid question, but I have not been
able to find an answer in the matplotlib documentation...
When plotting data points using the "o"-style, some points are truncated
by the axis borders. Is there a way to define some kind of margin
without changing the x/y range manually?
So far, I did some kind of workaround:
(xmin,xmax) = p.xlim()
xw = xmax - xmin
p.xlim(xmin - xw*0.05, xmax + xw*0.05)
Is there a better way than this?
Thanks,
Peter