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
(11)
2
(3)
3
(1)
4
(7)
5
(11)
6
(6)
7
(3)
8
(6)
9
10
(1)
11
(4)
12
(5)
13
(7)
14
(8)
15
16
(2)
17
(3)
18
19
(1)
20
(7)
21
(7)
22
23
24
(1)
25
(2)
26
(7)
27
(8)
28
(3)
29
(6)
30
31






Showing 5 results of 5

From: John H. <jdh...@ac...> - 2004年10月12日 22:52:33
 Humufr> Hi, like other people in these list, I can't
 Humufr> compile matplotlib anymore with pygtk 2.4. I have the same
 Humufr> error than the others. I don't know C so I understand
 Humufr> nothing in these message. Someone was arriving to correct
 Humufr> this problem please?
The failure occurs at line 8 of src/_gtkagg.cpp; there is no
matplotlib code on line 8 or above, so I do not believe it is a
matplotlib problem. I think it is either a pygtk problem or a problem
with your environment (does your pkg-config point to the proper pygtk
install path?). Below is a c++ file that is identical to _gtkagg.cpp
up to the failing line, which is the gobject import. After that it
just prints hello world.
Try compiling it with (where the python include path should point to
Python.h)
 > g++ test.cpp `pkg-con-2.0` -I/usr/local/include/python2.3/
Are you using gcc-3.4? This seems to be a specific problem with
gcc-3.4 and pygtk-2.4. It would be helpful if you post your gcc
version, platform and pygtk version.
Please let me know if you learn anything else. If you fail to compile
the minimal example below, check your pygtk pkg-config paths and
consider posting this example to the pygtk mailing list; Niklas posted
and got no response, but he didn't have a minimal example which will
make a world of difference in people's ability to help.
Unfortunately, I don't have access to a machine with gcc-3.4 and the
latest pygtk to test with.
//test.cpp
#include <cstring>
#include <cerrno>
#include <cstdio>
#include <iostream>
#include <cmath>
#include <utility>
#include <pygobject.h>
int main() {
 std::cout << "hello gtk" << std::cout;
}
From: Humufr <hu...@ya...> - 2004年10月12日 20:41:58
 Hi,
like other people in these list, I can't compile matplotlib anymore with 
pygtk 2.4. I have the same error than the others. I don't know C so I 
understand nothing in these message. Someone was arriving to correct 
this problem please?
Thanks,
 Nicolas
building 'matplotlib.backends._gtkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -Isrc 
-Iagg22/include -I. -I/usr/local/include -I/usr/include 
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -Isrc/freetype2 
-Iagg22/include/freetype2 -I./freetype2 -I/usr/local/include/freetype2 
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include 
-I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
-I/usr/include/python2.3 -c src/_gtkagg.cpp -o 
build/temp.linux-i686-2.3/src/_gtkagg.o
In file included from /usr/include/python2.3/Python.h:8,
 from /usr/include/pygtk-2.0/pygobject.h:5,
 from src/_gtkagg.cpp:8:
/usr/include/python2.3/pyconfig.h:856:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from /usr/include/string.h:26,
 from /usr/include/c++/3.3/cstring:51,
 from src/_gtkagg.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the 
previous definition
In file included from src/_gtkagg.cpp:8:
/usr/include/pygtk-2.0/pygobject.h:140: error: parse error before `typename'
/usr/include/pygtk-2.0/pygobject.h:147: error: parse error before `typename'
error: command 'gcc' failed with exit status 1
From: John H. <jdh...@ac...> - 2004年10月12日 14:12:25
>>>>> "BDayton" == BDayton <BD...@co...> writes:
 BDayton> Hi,
 BDayton> I have produced a figure and used 'fill' to plot regions
 BDayton> in that figure. I wanted to place a legend for it, but
 BDayton> when I tried it only the labels appeared - no coloured
 BDayton> squares indicating the colours of the fills, as you get
 BDayton> in Matlab. Is it possible to do this? I noticed in one of
 BDayton> the example scripts that it works with a barchart. I
 BDayton> would like to use it in the same way, but with 'fill's.
In matplotlib/legend.py, on line 182, try replacing 
 elif isinstance(handle, Rectangle):
with 
 elif isinstance(handle, Patch):
and try again. If it fails, please send in an example script that
exposes the problem, but let me know in any case. Note this solution
will still draw a little rectangle in the legend rather than a
miniature polygon the same shape as the fill one, but it will
otherwise have the same properties (eg facecolor). What does matlab do?
Cheers,
JDH
From: <BD...@co...> - 2004年10月12日 07:09:39
Hi,
I have produced a figure and used 'fill' to plot regions in that figure. I
wanted to place a legend for it, but when I tried it only the labels
appeared - no coloured squares indicating the colours of the fills, as you
get in Matlab. Is it possible to do this? I noticed in one of the example
scripts that it works with a barchart. I would like to use it in the same
way, but with 'fill's.
Cheers,
Brionie
==============================================
"The information contained in this e-mail message may be confidential information, and may also be privileged. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify us by return email and delete the original message."
From: Alexander S. <a.s...@gm...> - 2004年10月12日 00:25:52
Hi,
First of all let me congratulate you[1] on your work on Matplotlib -- it so
evidently superior to all the other stuff around for python that it might
actually obviate the need for a little "universal" plotting frontend (anyplot
) as matplotlib is the first such package that would deserve to become a
de-facto standard for plotting in python.
Nonetheless, I've already written most of the foundations and I think it might
actually still be useful (currently e.g. matplotlib still is a bit difficult
to install, and whilst the CVS version apparently already has quite good
support for interactive plotting, at least some features such as good 3D
plotting will likely take longer; and matlab, which is fully supported as
backend for anyplot will likely maintain an edge for a number of plotting
tasks for the immediate future)[2].
To come to the point, recently I've invested a little bit of time to add
matplotlib support[3] and whilst I have been generally postively surprised [4]
both by the quality of the output as well as the ease to get things to work,
there are still a few comments and questions I have:
Here are some things that would be nice to see:
 - AFAICT there is no equivalent to matlab's .fig internal format -- this
 is quite a shame, one of the reasons I why I think a fairly simple
 wrapper like anyplot should get one quite a long way is that I'd guess
 that when excellent visual results are actually important then the
 easiest way might well be to create some "templates" with the
 gui/backend specific commands and use them as prototypes/style-sheets.
 It should of course also be possible to query the underlying plotting
 package and use it's unique functionality where required; there are a
 few places in my code that do that for matlab but it's really not needed
 often and thus doesn't hamper migrating to another backend much.
 I'm planning to adding was some 'record'/'playback' functionality with a
 metaclass i.e. some internal anyplot specific save-format that can be
 used to recreate plots with any available backend -- but this is no full
 substitute because it will only (portably) work for things supported by
 all backends.
 - gcf returns a figure handle -- it would be nice if there were some obvious
 way to get back an integer instead -- I haven't found one yet
 - the LaTeX rendering backend unfortunatly doesn't support any accents
 (\hat{a},\bar{x} etc.); also for me the fact that it doesn't accept normal
 text with $math$ inside happens to be quite a bother -- I can't imagine that
 either of these would be hard to fix.
 - colormap is rather limited in matlab compatibility -- it would be at
 least having some of matlab's colormaps around as functions like `jet`.
 - `ishold` and `spy` are amongst the functions that are missing but would
 be quite easy to add -- ishold in particular would be very useful
 (unlike with gcf I quickly found some way to query the hold-state, but
 that interface might change and anyway it's a generally useful
 facility).
 - plot apparently doesn't know about the "*"-marker style -- this looks
 like a mere oversight (I think all the other marker styles that matlab
 has are supported)
 - the plot command is much more restrictive in what it accepts as inputs;
 ``plot(x1,y2,'r', x2,y2, 'b')`` e.g. would be illegal. This isn't much
 of a problem for me since I've written some code to "parse" plot
 arguments, but I think it's a bit inconvenient. For anyplot I've added
 some more options since I for example found I mainly wanted to use
 several y-vectors against a single x it is also possible to do something
 like e.g ``plot(y1, 'r', y2, 'g+', y3, ':', x='auto', norm=1,
 log='x')``. OTOH I think it might be best to be conservative about
 adding such features before one has a good idea what common use patterns
 are likely to look like (convenience functions could provide a good
 testbed for such ideas). 
 - something like axis('manual') would be nice (maybe under a more
 descriptive name) otherwise it's inconvenient to add additional plots
 into boundaries defined by some original plot that is of main interest.
 Unfortunately axis is one of matlab's slightly more overloaded functions
 -- in many of these cases one would think that python's more flexible
 parameter passing syntax (keywords, inter alia) would allow better
 signatures than what matlab's designers came up with (as far as I can
 see matplotlib already makes quite a lot of use kwargs)
Generally anyplot stays closer to matlab in it's interface, but there
are two commands I found too ugly to follow suit exactly:
- matlab's ``text(x,y,[z], string)`` is ``anyplot.text(string, x,y,[z])``
 Is there already a plan what matplotlib going to do about z coords for text,
 once it supports 3D plots?
- `subplot` is just too bloody awkward -- so I deprecated it and instead
 added a `multi` and `refocus` commands, here are the signatures::
 def multi(self,rows,cols=1):
 """Create a multiplot with specified number of `rows` and `cols`. Use
 `refocus` to access the desired cell. Supersedes `subplot`.
 see: `refocus`
 """
 def refocus(self,M=None,N=None):
 """Change focus to the desired subplot in a figure.
 - ``refocus()``
 focus on next multiplot cell (order: right-to-left,
 top-to-down, 0 index)
 - ``refocus(M)``
 focuses on multiplot cell ``M`` (order: same as above)
 - ``refocus(M,N)``
 focuses on multiplot cell at row ``M``, column ``N``
 see: `multi`
 """
I'd generally like to keep anyplot's interface the same as (or at least a
subset or superset of) matplotlib's where ever it makes sense, I'm not quite
convinced about `text` though (I'm not sure how useful z coords for text
really are, if they aren't used even with 3D plot passing them as a keyword,
unfortunately keywords are used to update the font dict; maybe a better
approach would be to use something like (ignoring details like the ordering of
coords and text for the moment)::
 fontInfo = FontInfo(font='Helvetica', height=13, etc='...')
 text(str1, x1, y1 font=fontInfo(height=10))
 text(str2, x2, y2 font=fontInfo(color='red'))
instead of::
 fontInfo = {'font': 'Helvetica', 'height': 13, etc:'...'}
 text(str1, x1, y1 fontdict=fontInfo, height=10)
 text(str2, x2, y2 fontdict=fontInfo, color='red')
because that doesn't scale so well (one no longer can simply add keywords args
for non font-info stuff).
Here `fontInfo` is some structure type that on call creates an updated *copy*.
I've found this quite useful for other things so I've got an implementation
handy: [5]
I'm also wondering how much the interface has already settled down? BTW, one
thing that would be nice is if any sequence dependent quirks (where
unavoidable) would be the same as in matlab, because that would be quite
difficult to work around in anyplot otherwise (e.g. the order of `title`,
`subplot` and `plot`, IIRC; some like the way plot interacts with logplots and
hold might be easier to work around -- I'm still not sure what the best
behavior ist does matplotlib have any fixed policy here already?).
Cheers,
'as
P.S. I will be off-line for about a month from tomorrow noon onwards, so please
 excuse extreme reply latencies ;) -- I'm unlikely to read anything for
 a month that posted after the next 10/12hrs.
P.P.S. For those who are curious about anyplot, my imminent long off-line
 period finally gave me the push to try to package up all the
 non-pre-alpha stuff I've created over the years and put it on a web
 page in the hope it might be useful for other. Thus hopefully, by
 tomorrow you anyplot and some other possibly useful stuff like my
 high-level matlab-bridge can be found here:
 http://www.dcs.ex.ac.uk/~aschmolc/
 (In the possibly unlikely event that there's some code that would be
 useful for matplotlib -- don't hestitate to take it, license issues
 should be no problem)
P.P.S. A final note: wouldn't it be nicer to have some python-syntax rc file?
 It can always be a safe subset if there are security concerns, but I'd
 rather not have yet another limited and (difficult to extend)
 config-file syntax.
Footnotes: 
[1] you here refers to everyone who helped to rapidly transform matplotlib
 into a the to be reckoned with, rather than the zillionth half-arsed and
 bug-ridden plotting package to linger around for years without getting
 anywhere -- first and foremost that credit must of course belong to John
 Hunter.
[2] I started it because I became frustrated with the code disruption caused by
 switching from one unsatisfactory python plotting package to the next I
 started a little, as yet unreleased project some time ago that I dubbed
 anyplot (after the now apparently defunct anygui project). The aim was to
 provide a uniform and (esp. for interactive work) efficient frontend to a few
 different promising backends, because
 a) at the time it wasn't clear on what horse to bet (all of them lamed a bit,
 and the ones that offered most functionality also seemed to suffer from the
 most deeply ingrained problems). 
 
 b) Different plotting packages for python did different things well so it
 seemed useful to easily be able to use specific backend for a certain task
 without having to deal with code changes or memorzing N-interfaces; the
 only one that did everything fairly well was matlab, via the high-level
 python-matlab bridge I wrote, but even matlab often leaves something to be
 desired and I didn't particularly want to be tied to it for eternity. For
 the past 1.5 years or I've almost exclusively used anyplot with matlab as
 backend for all my work, so that part should be fairly stable.
 
 c) Moreover most had rather painful interfaces -- I wanted something that was
 quick and convenient to use for interactive data exploration. I noticed
 that the vast majority of the time I didn't need fancier capabilities (or
 used the GUI to fine-tune the results), so I reckoned that providing a
 convenient set would be a useful and manageable task, much more so than
 what anypgui set out to do for GUIs. I also took matlab as a point of
 departure, because it is familiar to many people, but also because despite
 some baroqueness the interface is quite quick and efficient for common
 tasks (unlike many of the interfaces that strive for OO-purity).
 
[3] apart from that, at the moment there's also some xplt support, xplt is
 sufficiently dodgy that I won't invest much further time on this but it
 provides a IMO saner interface to most of the functionality; there's also
 some rather preliminary support for grace, which despite being somewhat
 limited in the type of plots it offers seems to do a few things quite
 well, is very fast and offers a fairly convenient gui; the only thing I'd
 still be interested in additionally supporting would be gnuplot, although
 some of gnuplots weirder limitations (e.g. line styles) would cause some
 awkwardness -- the good thing about gnuplot, though, is that it supports
 both 3D and 2D, zillions of output formats (including more exotic ones
 like ascii, latex and vt100), that it is widespread and runs just about
 on anything and finally that it won't go away anytime soon.
[4] Apart from the installation; I'm a bit spoilt as most libraries I want
 under debian just takes seconds to instal -- I had some trouble with the
 latest sources and eventually downloaded a debian package by hand from
 somewhere because that seemed the only way to get it to work.
[5] Here's the code (obviously not all of this class are would be needed, but
 it should give the idea; also note that it's very convenient to convert
 to/from dicts):
class Struct(object):
 r"""
 Examples:
 
 >>> brian = Struct(name="Brian", age=30)
 >>> brian.name
 'Brian'
 >>> brian.age
 30
 >>> brian.life = "short"
 >>> brian
 Struct(age=30, life='short', name='Brian')
 >>> del brian.life
 >>> brian == Struct(name="Brian", age=30)
 True
 >>> brian != Struct(name="Jesus", age=30)
 True
 >>> len(brian)
 2
 Call the object to create a clone:
 
 >>> brian() is not brian and brian(name="Jesus") == Struct(name="Jesus", age=30)
 True
 Conversion to/from dict:
 >>> Struct(**dict(brian)) == brian
 True
 Evil Stuff:
 
 >>> brian['name', 'age']
 ('Brian', 30)
 >>> brian['name', 'age'] = None, None
 >>> brian
 Struct(age=None, name=None)
 """
 def __init__(self,**kwargs):
 self.__dict__.update(kwargs)
 def __call__(self, **kwargs):
 import copy
 res = copy.copy(self)
 res.__init__(**kwargs)
 return res
 def __eq__(self, other):
 return self.__dict__ == other.__dict__
 def __ne__(self, other):
 return not self.__eq__(other)
 def __len__(self):
 return len([k for k in self.__dict__.iterkeys() if not (k.startswith('__') or k.endswith('__'))])
 # FIXME utterly perverse and UNTESTED
 def __getitem__(self, nameOrNames):
 if isString(nameOrNames):
 return self.__dict__[nameOrNames]
 else:
 return tuple([self.__dict__[n] for n in nameOrNames])
 # FIXME utterly perverse and UNTESTED 
 def __setitem__(self, nameOrNames, valueOrValues):
 if isString(nameOrNames):
 self.__dict__[nameOrNames] = valueOrValues
 else:
 for (n,v) in zip(nameOrNames, valueOrValues):
 self.__dict__[n] = v
 def __contains__(self, key):
 return key in self.__dict__ and not (key.startswith('__') or key.endswith('__'))
 def __iter__(self):
 for (k,v) in self.__dict__.iteritems():
 if not (k.startswith('__') or k.endswith('__')):
 yield k,v
 def __repr__(self):
 return mkRepr(self, **vars(self))
def mkRepr(instance, *argls, **kwargs):
 width=79
 maxIndent=15
 minIndent=2
 args = map(repr, argls) + ["%s=%r" % (k, v)
 for (k,v) in ipsort(kwargs.items())]
 if instance is not None:
 start = "%s(" % instance.__class__.__name__
 args[-1] += ")"
 else:
 start = ""
 if len(start) <= maxIndent and len(start) + len(args[0]) <= width and \
 max(map(len,args)) <= width: # XXX mag of last condition bit arbitrary
 indent = len(start)
 args[0] = start + args[0]
 if sum(map(len, args)) + 2*(len(args) - 1) <= width:
 return ", ".join(args)
 else:
 indent = minIndent
 args[0] = start + "\n" + " " * indent + args[0]
 return (",\n" + " " * indent).join(args)

Showing 5 results of 5

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 によって変換されたページ (->オリジナル) /