SourceForge logo
SourceForge logo
Menu

matplotlib-users — Discussion related to using matplotlib

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
(3)
Jun
Jul
Aug
(12)
Sep
(12)
Oct
(56)
Nov
(65)
Dec
(37)
2004 Jan
(59)
Feb
(78)
Mar
(153)
Apr
(205)
May
(184)
Jun
(123)
Jul
(171)
Aug
(156)
Sep
(190)
Oct
(120)
Nov
(154)
Dec
(223)
2005 Jan
(184)
Feb
(267)
Mar
(214)
Apr
(286)
May
(320)
Jun
(299)
Jul
(348)
Aug
(283)
Sep
(355)
Oct
(293)
Nov
(232)
Dec
(203)
2006 Jan
(352)
Feb
(358)
Mar
(403)
Apr
(313)
May
(165)
Jun
(281)
Jul
(316)
Aug
(228)
Sep
(279)
Oct
(243)
Nov
(315)
Dec
(345)
2007 Jan
(260)
Feb
(323)
Mar
(340)
Apr
(319)
May
(290)
Jun
(296)
Jul
(221)
Aug
(292)
Sep
(242)
Oct
(248)
Nov
(242)
Dec
(332)
2008 Jan
(312)
Feb
(359)
Mar
(454)
Apr
(287)
May
(340)
Jun
(450)
Jul
(403)
Aug
(324)
Sep
(349)
Oct
(385)
Nov
(363)
Dec
(437)
2009 Jan
(500)
Feb
(301)
Mar
(409)
Apr
(486)
May
(545)
Jun
(391)
Jul
(518)
Aug
(497)
Sep
(492)
Oct
(429)
Nov
(357)
Dec
(310)
2010 Jan
(371)
Feb
(657)
Mar
(519)
Apr
(432)
May
(312)
Jun
(416)
Jul
(477)
Aug
(386)
Sep
(419)
Oct
(435)
Nov
(320)
Dec
(202)
2011 Jan
(321)
Feb
(413)
Mar
(299)
Apr
(215)
May
(284)
Jun
(203)
Jul
(207)
Aug
(314)
Sep
(321)
Oct
(259)
Nov
(347)
Dec
(209)
2012 Jan
(322)
Feb
(414)
Mar
(377)
Apr
(179)
May
(173)
Jun
(234)
Jul
(295)
Aug
(239)
Sep
(276)
Oct
(355)
Nov
(144)
Dec
(108)
2013 Jan
(170)
Feb
(89)
Mar
(204)
Apr
(133)
May
(142)
Jun
(89)
Jul
(160)
Aug
(180)
Sep
(69)
Oct
(136)
Nov
(83)
Dec
(32)
2014 Jan
(71)
Feb
(90)
Mar
(161)
Apr
(117)
May
(78)
Jun
(94)
Jul
(60)
Aug
(83)
Sep
(102)
Oct
(132)
Nov
(154)
Dec
(96)
2015 Jan
(45)
Feb
(138)
Mar
(176)
Apr
(132)
May
(119)
Jun
(124)
Jul
(77)
Aug
(31)
Sep
(34)
Oct
(22)
Nov
(23)
Dec
(9)
2016 Jan
(26)
Feb
(17)
Mar
(10)
Apr
(8)
May
(4)
Jun
(8)
Jul
(6)
Aug
(5)
Sep
(9)
Oct
(4)
Nov
Dec
2017 Jan
(5)
Feb
(7)
Mar
(1)
Apr
(5)
May
Jun
(3)
Jul
(6)
Aug
(1)
Sep
Oct
(2)
Nov
(1)
Dec
2018 Jan
Feb
Mar
Apr
(1)
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
2020 Jan
Feb
Mar
Apr
May
(1)
Jun
Jul
Aug
Sep
Oct
Nov
Dec
2025 Jan
(1)
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
S M T W T F S



1
(36)
2
(10)
3
(8)
4
5
(4)
6
(15)
7
(17)
8
(3)
9
(8)
10
(5)
11
(2)
12
(5)
13
(5)
14
(15)
15
(3)
16
(10)
17
(6)
18
(2)
19
(1)
20
(11)
21
(33)
22
(13)
23
(14)
24
(15)
25
(4)
26
(5)
27
(9)
28
(12)
29
(7)
30
(8)
31
(6)

Showing 11 results of 11

From: Eric F. <ef...@ha...> - 2007年08月20日 23:57:10
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. 
> 
> 
From: Anthony M. F. <Ant...@co...> - 2007年08月20日 23:40:21
> -----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
From: Eric F. <ef...@ha...> - 2007年08月20日 22:53:50
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
From: Anthony M. F. <Ant...@co...> - 2007年08月20日 22:01:19
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
From: Johann Cohen-T. <co...@sl...> - 2007年08月20日 20:07:15
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
>
From: Eric F. <ef...@ha...> - 2007年08月20日 19:49:00
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
From: John T. <jt...@gm...> - 2007年08月20日 19:00:21
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
From: Alan G I. <ai...@am...> - 2007年08月20日 18:55:45
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
From: Johann Cohen-T. <co...@sl...> - 2007年08月20日 18:51:37
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
From: Darren D. <dd...@co...> - 2007年08月20日 18:26:48
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?
From: Samuel M. S. <sm...@sa...> - 2007年08月20日 16:11:37
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"
**********************************************************************

Showing 11 results of 11

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /