matplotlib-devel Mailing List for matplotlib

> Agreed. I know there are still some matplotlib users on python2.3, but
> they'll have to move on eventually... ;)
Yes, we decided to drop support for python2.3, because we use
decorators. But I am not going to drop support for 2.4, because
Debian (my distribution) still uses it by default. :)
> >> I generally don't like ctypes-based wrappers since changes in the
> >> dependency can mean segfaults at runtime. I'm having a problem getting
> >> pyglet to work on my particular version of OpenGL, for instance. But
> >> perhaps freetype is stable enough for that not to be a problem.
> >
> > Could you please report it to http://groups.google.com/group/pyglet-users ?
>
> Sorry -- I should have mentioned I already did.
Ah, so mdboom is you? I saw the headline, but I didn't look further.
Nice bug report!
> > So it's needed for path collections - what is that?
>
> A collection of a large number of paths (or polygons) that need to be
> rendered quickly.
>
> > When I want to do
> > regular plots,
> > like plotting some set of points, is that needed too? If not, it
> > should be optional imho.
>
> That's actually a tough one. On the transforms branch, by the time it
> hits the rendering level, everything is a polycurve path. Determining
> if something contains curves or not (which in the current implementation
> would require running through the entire path, which may be quite large)
> would probably be too slow.
I see. In this case, it's probably not worthy to create pure python kernel.
We do have some 2D plotting already, it's fast enough. But it
doesn't contain so many nice features of matplotlib.
> There are. But the multiple versions of the library must be
> individually tested to have a hope of working -- whereas with the
> compiled model, sometimes the changes between library versions will be
> seamless, other times the compile will fail, both of which are
> preferable to segfaulting at runtime (which admittedly is still possible
> even when compiling.)
I got it now. That's right.
> >> Great! I'll start by looking at pyglet's freetype wrapper and see how
> >> far I get.
> >
> > Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
> > will answer any technical questions.
>
> Thanks,
Since you already asked, let's wait. :)
> > Granted, this page is getting a little dated, but here's what you get
> > with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
>
> Thanks, that's the link I was basically quoting from memory, which I'd
> read when you posted it a while ago. Great reference on this topic.
That's nice enough for me. Don't forget, that I am comparing no
plotting, to some plotting.
Well, definitely, we try to support good interaction with external
packages, like numpy
and matplotlib. But builtin is builtin. :)
Ondrej
Ondrej

On Jan 4, 2008 1:04 PM, Andrew Straw <str...@as...> wrote:
> Excellent summary, Fernando -- are looking to burnish your visual
> neuroscientist credentials? ;)
Gotta start somewhere, no? :) Now I just have to convince the NSF
it's true as well... Back to grant writing :)
> > The other issue I recall is that the quality of openGL antialiasing is
> > highly dependent on the video card and/or driver. While that may be
> > OK for gamers, it's completely unacceptable IMO for scientific
> > publication.
>
>
> Granted, this page is getting a little dated, but here's what you get
> with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
Thanks, that's the link I was basically quoting from memory, which I'd
read when you posted it a while ago. Great reference on this topic.
Cheers,
f

On Jan 4, 2008, at 1:08 PM, Fernando Perez wrote:
> No worries, you misunderstood me :) My point was that a linux
> developer could keep a vwmare image around to produce the binary
> windows *installer* for win32 users, if there were compiled code
> around.
Oh.
That's all right, then.
Sorry.
(Actually I might be a tad more Windows-neutral, as Python gets us 
halfway there... so far our user community hasn't asked for it, whew!)
(lurking resumes...)
 - boyd

On Jan 4, 2008 1:00 PM, Ondrej Certik <on...@ce...> wrote:
>
> On Jan 4, 2008 8:44 PM, Darren Dale <dar...@co...> wrote:
> > Why would your users have to compile anything on windows? Matplotlib's windows
> > users just run the installer, the compilation has already been done. Am I
> > missing something?
As I mentioned, it does meant that the project does need a volunteer
to *produce* the win32 installers. That might be trivial (if that
person already exists) or could require some work, but it's not
insurmountable (and as I hinted, with virtualization that person can
even be one of the regular unix people with only limited pain).
Cheers,
f

On Jan 4, 2008 1:04 PM, Boyd Waters <bw...@nr...> wrote:
>
> On Jan 4, 2008, at 12:44 PM, Fernando Perez wrote:
>
> > Indeed, compiled code in a project basically forces you to have a
> > windows developer in the team who can build the binary installers.
> > These days with vmware/qemu it's not the end of the world (it can be
> > done in a normal computer running linux/osx) but it's still a pain for
> > most of us, no doubt about it.
>
>
> Not to open a can of trolls here, but I must strongly disagree.
>
> Why does "compiled code" mean "Windows"?
No worries, you misunderstood me :) My point was that a linux
developer could keep a vwmare image around to produce the binary
windows *installer* for win32 users, if there were compiled code
around. I was just explaining how even if the project has no windows
volunteers on hand to generate the installers, this isn't
insurmountable these days thanks to vmware. You still need a
linux/osx dev who's willing to install virtualized windows and
compiler, but that's a lower requirement than asking one of us to
switch to win32 altogether :)
Relax, anyone who knows me has already seen how big of a fan of win32 I am ;)
Cheers,
f

Ondrej Certik wrote:
> On Jan 4, 2008 7:41 PM, Michael Droettboom <md...@st...> wrote:
>> Ondrej Certik wrote:
>>> * freetype (this could be rewritten using ctypes)
>> I see that pyglet already has a freetype wrapper using ctypes -- it
>> would be interesting to see if that could be used as a starting point.
>> That could be used as a starting point. (Of course, ctypes is an
>> external dependency before Python-2.5, which adds a dependency to
>> matplotlib).
> 
> That is correct. I forgot about that. We do support python2.4 and it's
> true that in order
> for plotting to work, you need to install python-ctypes.
> But python2.4 will hopefully get old soon, in favor of python2.5.
Agreed. I know there are still some matplotlib users on python2.3, but 
they'll have to move on eventually... ;)
>> I generally don't like ctypes-based wrappers since changes in the
>> dependency can mean segfaults at runtime. I'm having a problem getting
>> pyglet to work on my particular version of OpenGL, for instance. But
>> perhaps freetype is stable enough for that not to be a problem.
> 
> Could you please report it to http://groups.google.com/group/pyglet-users ?
Sorry -- I should have mentioned I already did.
>>> * Agg (this could be optional)
>> On the transforms branch, Agg is used for bezier curve realisation,
>> whether the Agg renderer is being used or not. This is used for things
>> like hit-testing and range-setting of path collections etc. This was
>> not fast enough in my earlier numpy-based implementation, since to take
>> advantage of numpy, you generally have to allocate lots of memory to
>> store the results in. In this particular case, each value can be
>> immediately thrown away, so all that extra work was unnecessary.
> 
> So it's needed for path collections - what is that? 
A collection of a large number of paths (or polygons) that need to be 
rendered quickly.
> When I want to do
> regular plots,
> like plotting some set of points, is that needed too? If not, it
> should be optional imho.
That's actually a tough one. On the transforms branch, by the time it 
hits the rendering level, everything is a polycurve path. Determining 
if something contains curves or not (which in the current implementation 
would require running through the entire path, which may be quite large) 
would probably be too slow.
>>> Compiling really sucks.
>> Agreed. But there is a spectrum of suckage here. It also sucks to be
>> unable to check that a call to some library that you don't provide
>> (freetype) will succeed.
> 
> That sucks too. But I think there are mechanisms to check the exact version
> of the library, aren't there?
There are. But the multiple versions of the library must be 
individually tested to have a hope of working -- whereas with the 
compiled model, sometimes the changes between library versions will be 
seamless, other times the compile will fail, both of which are 
preferable to segfaulting at runtime (which admittedly is still possible 
even when compiling.)
>>>>> Another cool stuff in matplotlib is the pure python latex renderer
>>>>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
>>>>> more info:
>>>> Yes, the mathtext support in matplotlib is very nice, and Michael
>>>> deserves the credit for taking from a package that
>>>> works but has warts, to an extremely nice math layout engine using the
>>>> Knuth algorithms. I'm sure others would like to use it without having
>>>> to pull in all of matplotlib. With a ctypes freetype wrapper, it
>>>> should be possible to build a free-standing mathtext.
>>> And this is really cool. I would like to have that. :)
>>>
>>> We'll try to help with that one.
>> Great! I'll start by looking at pyglet's freetype wrapper and see how
>> far I get.
> 
> Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
> will answer any technical questions.
Thanks,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jan 4, 2008, at 12:44 PM, Fernando Perez wrote:
> Indeed, compiled code in a project basically forces you to have a
> windows developer in the team who can build the binary installers.
> These days with vmware/qemu it's not the end of the world (it can be
> done in a normal computer running linux/osx) but it's still a pain for
> most of us, no doubt about it.
Not to open a can of trolls here, but I must strongly disagree.
Why does "compiled code" mean "Windows"?
I'd recommend that some OpenGL layer be used from Python. Use automake 
for the build system.
We'd have to drop Matplotlib if it required Windows; at the moment we 
only have Linux and Macintosh developers (the Mac got in because it's 
a Unix platform, but it still took some porting).
I believe that many other scientific research organizations have many 
Unix boxes and few Windows machines for their analysis workstations. I 
know it's true of the astronomy places that I've visited, but I 
haven't seen other science in a while so perhaps Windows has taken 
over science, too. But at our facility we can't support Windows for 
scientific development.
/me runs away, covering head...
;-)
 - boyd
Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
Socorro, New Mexico

Fernando Perez wrote:
> It's probably worth mentioning that one of the reasons John chose Agg
> is because of image *quality* concerns. If I'm not mistaken (John and
> A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> is positively horrible when you compare it to the quality of Agg.
> Keep in mind that OpenGL is typically focused on keeping high
> frame-rates for moving images, so pixel-perfect antialiasing is much
> less of a concern for them, since your eye is a lot less likely to
> notice such fine details (as long as there is *some* antialiasing).
> For a static image, you tend to be a lot pickier, and Agg goes to
> great lengths to ensure the best possible antialiasing quality. This
> is part of the reason why normal television, at abysmally low
> resolutions is still acceptable for viewing, while nobody would
> consider a 400-line-image an acceptable photograph for most uses. You
> 'stare' at the moving image only for 1/30 s or so, while you look at
> the static one for much longer.
Excellent summary, Fernando -- are looking to burnish your visual
neuroscientist credentials? ;) The only thing I'd add is that the
spatio-temporal nature of video means that, despite course spatial
quantization on any single image, we perceive something with a much
higher resolution essentially because we have many samples where the
source is moving against the sampling array and we "fill in". Not only
do we do this, so do our electronic devices these days -- upsampling
(spatially and temporally) DVD players make use of algorithms to fill in
pixels that weren't directly specified. And video compression codecs
essentially remove information that's perceptually less significant to
this filling in process. (Stop me here...)
> I've never seen any opengl-based antialiasing be of that quality. But
> there may be ways of achieving the same thing in OpenGL, I don't know
> (and to do so efficiently and portably, without requiring specific
> video cards).
>
> The other issue I recall is that the quality of openGL antialiasing is
> highly dependent on the video card and/or driver. While that may be
> OK for gamers, it's completely unacceptable IMO for scientific
> publication.
Granted, this page is getting a little dated, but here's what you get
with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
FWIW, one cheap trick to get better anti-aliasing with OpenGL is to
render the image much bigger than you need and then downsample it
appropriately. As OpenGL implementations have maximum rendering sizes,
this often means tiling the image. This probably wouldn't work for
realtime rendering, but for saving bitmaps it would produce decent results.
In general, I think we should explore collaboration (and I'm very
excited about the sympy project). Yet, it's difficult for me to see how
MPL could be turned into a pure-Python project with acceptable speed and
retaining the backends that we support with the quality we support. All
the more so with the new transforms branch.

On Jan 4, 2008 8:44 PM, Darren Dale <dar...@co...> wrote:
>
> On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote:
> > On Jan 4, 2008 8:19 PM, Fernando Perez <fpe...@gm...> wrote:
> > > On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote:
> > > > > > * Agg (this could be optional)
> > > > >
> > > > > On the transforms branch, Agg is used for bezier curve realisation,
> > > > > whether the Agg renderer is being used or not. This is used for
> > > > > things like hit-testing and range-setting of path collections etc.
> > > > > This was not fast enough in my earlier numpy-based implementation,
> > > > > since to take advantage of numpy, you generally have to allocate lots
> > > > > of memory to store the results in. In this particular case, each
> > > > > value can be immediately thrown away, so all that extra work was
> > > > > unnecessary.
> > > >
> > > > So it's needed for path collections - what is that? When I want to do
> > > > regular plots,
> > > > like plotting some set of points, is that needed too? If not, it
> > > > should be optional imho.
> > >
> > > It's probably worth mentioning that one of the reasons John chose Agg
> > > is because of image *quality* concerns. If I'm not mistaken (John and
> > > A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> > > is positively horrible when you compare it to the quality of Agg.
> > > Keep in mind that OpenGL is typically focused on keeping high
> > > frame-rates for moving images, so pixel-perfect antialiasing is much
> > > less of a concern for them, since your eye is a lot less likely to
> > > notice such fine details (as long as there is *some* antialiasing).
> > > For a static image, you tend to be a lot pickier, and Agg goes to
> > > great lengths to ensure the best possible antialiasing quality. This
> > > is part of the reason why normal television, at abysmally low
> > > resolutions is still acceptable for viewing, while nobody would
> > > consider a 400-line-image an acceptable photograph for most uses. You
> > > 'stare' at the moving image only for 1/30 s or so, while you look at
> > > the static one for much longer.
> > >
> > > Just look at some of their examples to get an idea of what I'm talking
> > > about:
> > >
> > > http://www.antigrain.com/screenshots/index.html
> > >
> > > I've never seen any opengl-based antialiasing be of that quality. But
> > > there may be ways of achieving the same thing in OpenGL, I don't know
> > > (and to do so efficiently and portably, without requiring specific
> > > video cards).
> > >
> > > The other issue I recall is that the quality of openGL antialiasing is
> > > highly dependent on the video card and/or driver. While that may be
> > > OK for gamers, it's completely unacceptable IMO for scientific
> > > publication.
> > >
> > > > > > Compiling really sucks.
> > >
> > > Keep in mind that while python+cleverness can get you a lot of speed,
> > > there are operations that are *inescapably* slow in python's fully
> > > dynamic model today (without JIT-type tricks a la psyco that avoid
> > > dynamic dispatch in loops). Running a tight loop over a million
> > > elements of anything to do some repetitive operation will incur in
> > > Python's runtime check costs on every pass of the loop. In a plotting
> > > library, this type of computation is very frequent, and while some of
> > > it can be rolled into numpy-type array operations, that's not always
> > > possible. There's simply no way out (today) from compiled code for
> > > certain things in python, I'm afraid. Keep in mind that there are
> > > still people who regularly complain about MPL being *too slow* for
> > > their purposes, which involve interactive data exploration of enormous
> > > datasets. I'm sure that loss of speed would not be considered a
> > > desirable feature for a new MPL release by many :)
> > >
> > > I'm certainly hoping you guys can find some mechanism to join forces
> > > on this front, which I would absolutely love to see. But I just want
> > > to provide a bit of context as to why MPL uses extensions like Agg and
> > > relies on compiled code, which is I think a fairly critical need of
> > > the project.
> > >
> > > Having said all this, I'd be thrilled to be proven 100% wrong in all
> > > of the above, and to see a pure-python MPL that is as fast as today's
> > > and maintains the image quality we have today.
> > >
> > > One approach that has been thrown around in the past was to have an
> > > opengl based render while working interactively, that would force a
> > > re-render of the same entire scene via Agg for image saving. I don't
> > > know enough about the MPL internals to say how feasible this would be.
> >
> > Hi Fernando!
> >
> > what you said are valid points for matplotlib using Agg as a backend.
> > And as I said,
> > the default matplotlib installation should include it, no doubt about that.
> >
> > On the other hand, I (and I think many other users) only need the super
> > quality only when saving the final plot. Of course, if it's worth the pain,
> > I can install the agg
> > backend and have the quality all the time, but many users will
> > sacrifice the quality,
> > if they can get at least some plot.
> >
> > If it was just me, I use Debian, so for me using any C compiled code
> > is zero pain. But,
> > the majority of users of sympy, are probably windows users. (At least there
> > are more downloads of the windows installer, than the mulitplatform
> > tarball). And I am not sure compiling anything on windows is a pleasant
> > experience (honestly I
> > think forcing a user of sympy compiling something on windows is a show
> > stopper).
>
> Why would your users have to compile anything on windows? Matplotlib's windows
> users just run the installer, the compilation has already been done. Am I
> missing something?
Right, maybe what I am trying to achieve is not really worthy.
My idea is to have something integrated inside sympy, pure pythonic.
I don't really want to depend on anything else. Because for everything
else, there is Sage
(full featured CAS system, with all the programs). SymPy is just for
doing symbolic
manipulation in python.
Ondrej

On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote:
> On Jan 4, 2008 8:19 PM, Fernando Perez <fpe...@gm...> wrote:
> > On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote:
> > > > > * Agg (this could be optional)
> > > >
> > > > On the transforms branch, Agg is used for bezier curve realisation,
> > > > whether the Agg renderer is being used or not. This is used for
> > > > things like hit-testing and range-setting of path collections etc. 
> > > > This was not fast enough in my earlier numpy-based implementation,
> > > > since to take advantage of numpy, you generally have to allocate lots
> > > > of memory to store the results in. In this particular case, each
> > > > value can be immediately thrown away, so all that extra work was
> > > > unnecessary.
> > >
> > > So it's needed for path collections - what is that? When I want to do
> > > regular plots,
> > > like plotting some set of points, is that needed too? If not, it
> > > should be optional imho.
> >
> > It's probably worth mentioning that one of the reasons John chose Agg
> > is because of image *quality* concerns. If I'm not mistaken (John and
> > A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> > is positively horrible when you compare it to the quality of Agg.
> > Keep in mind that OpenGL is typically focused on keeping high
> > frame-rates for moving images, so pixel-perfect antialiasing is much
> > less of a concern for them, since your eye is a lot less likely to
> > notice such fine details (as long as there is *some* antialiasing).
> > For a static image, you tend to be a lot pickier, and Agg goes to
> > great lengths to ensure the best possible antialiasing quality. This
> > is part of the reason why normal television, at abysmally low
> > resolutions is still acceptable for viewing, while nobody would
> > consider a 400-line-image an acceptable photograph for most uses. You
> > 'stare' at the moving image only for 1/30 s or so, while you look at
> > the static one for much longer.
> >
> > Just look at some of their examples to get an idea of what I'm talking
> > about:
> >
> > http://www.antigrain.com/screenshots/index.html
> >
> > I've never seen any opengl-based antialiasing be of that quality. But
> > there may be ways of achieving the same thing in OpenGL, I don't know
> > (and to do so efficiently and portably, without requiring specific
> > video cards).
> >
> > The other issue I recall is that the quality of openGL antialiasing is
> > highly dependent on the video card and/or driver. While that may be
> > OK for gamers, it's completely unacceptable IMO for scientific
> > publication.
> >
> > > > > Compiling really sucks.
> >
> > Keep in mind that while python+cleverness can get you a lot of speed,
> > there are operations that are *inescapably* slow in python's fully
> > dynamic model today (without JIT-type tricks a la psyco that avoid
> > dynamic dispatch in loops). Running a tight loop over a million
> > elements of anything to do some repetitive operation will incur in
> > Python's runtime check costs on every pass of the loop. In a plotting
> > library, this type of computation is very frequent, and while some of
> > it can be rolled into numpy-type array operations, that's not always
> > possible. There's simply no way out (today) from compiled code for
> > certain things in python, I'm afraid. Keep in mind that there are
> > still people who regularly complain about MPL being *too slow* for
> > their purposes, which involve interactive data exploration of enormous
> > datasets. I'm sure that loss of speed would not be considered a
> > desirable feature for a new MPL release by many :)
> >
> > I'm certainly hoping you guys can find some mechanism to join forces
> > on this front, which I would absolutely love to see. But I just want
> > to provide a bit of context as to why MPL uses extensions like Agg and
> > relies on compiled code, which is I think a fairly critical need of
> > the project.
> >
> > Having said all this, I'd be thrilled to be proven 100% wrong in all
> > of the above, and to see a pure-python MPL that is as fast as today's
> > and maintains the image quality we have today.
> >
> > One approach that has been thrown around in the past was to have an
> > opengl based render while working interactively, that would force a
> > re-render of the same entire scene via Agg for image saving. I don't
> > know enough about the MPL internals to say how feasible this would be.
>
> Hi Fernando!
>
> what you said are valid points for matplotlib using Agg as a backend.
> And as I said,
> the default matplotlib installation should include it, no doubt about that.
>
> On the other hand, I (and I think many other users) only need the super
> quality only when saving the final plot. Of course, if it's worth the pain,
> I can install the agg
> backend and have the quality all the time, but many users will
> sacrifice the quality,
> if they can get at least some plot.
>
> If it was just me, I use Debian, so for me using any C compiled code
> is zero pain. But,
> the majority of users of sympy, are probably windows users. (At least there
> are more downloads of the windows installer, than the mulitplatform
> tarball). And I am not sure compiling anything on windows is a pleasant
> experience (honestly I
> think forcing a user of sympy compiling something on windows is a show
> stopper).
Why would your users have to compile anything on windows? Matplotlib's windows 
users just run the installer, the compilation has already been done. Am I 
missing something?
Darren

[ oops, this was meant to be on-list]
Hey Ondrej,
On Jan 4, 2008 12:36 PM, Ondrej Certik <on...@ce...> wrote:
> Hi Fernando!
>
> what you said are valid points for matplotlib using Agg as a backend.
> And as I said,
> the default matplotlib installation should include it, no doubt about that.
>
> On the other hand, I (and I think many other users) only need the super quality
> only when saving the final plot. Of course, if it's worth the pain, I
> can install the agg
> backend and have the quality all the time, but many users will
> sacrifice the quality,
> if they can get at least some plot.
>
> If it was just me, I use Debian, so for me using any C compiled code
> is zero pain. But,
> the majority of users of sympy, are probably windows users. (At least there are
> more downloads of the windows installer, than the mulitplatform tarball). And
> I am not sure compiling anything on windows is a pleasant experience
> (honestly I
> think forcing a user of sympy compiling something on windows is a show stopper).
Indeed, compiled code in a project basically forces you to have a
windows developer in the team who can build the binary installers.
These days with vmware/qemu it's not the end of the world (it can be
done in a normal computer running linux/osx) but it's still a pain for
most of us, no doubt about it.
Again, I was just trying to provide context. From where I stand, I'm
cheering as hard as I can for you guys to succeed.
Cheers,
f

On Jan 4, 2008 8:19 PM, Fernando Perez <fpe...@gm...> wrote:
> On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote:
>
> > > > * Agg (this could be optional)
> > >
> > > On the transforms branch, Agg is used for bezier curve realisation,
> > > whether the Agg renderer is being used or not. This is used for things
> > > like hit-testing and range-setting of path collections etc. This was
> > > not fast enough in my earlier numpy-based implementation, since to take
> > > advantage of numpy, you generally have to allocate lots of memory to
> > > store the results in. In this particular case, each value can be
> > > immediately thrown away, so all that extra work was unnecessary.
> >
> > So it's needed for path collections - what is that? When I want to do
> > regular plots,
> > like plotting some set of points, is that needed too? If not, it
> > should be optional imho.
>
> It's probably worth mentioning that one of the reasons John chose Agg
> is because of image *quality* concerns. If I'm not mistaken (John and
> A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> is positively horrible when you compare it to the quality of Agg.
> Keep in mind that OpenGL is typically focused on keeping high
> frame-rates for moving images, so pixel-perfect antialiasing is much
> less of a concern for them, since your eye is a lot less likely to
> notice such fine details (as long as there is *some* antialiasing).
> For a static image, you tend to be a lot pickier, and Agg goes to
> great lengths to ensure the best possible antialiasing quality. This
> is part of the reason why normal television, at abysmally low
> resolutions is still acceptable for viewing, while nobody would
> consider a 400-line-image an acceptable photograph for most uses. You
> 'stare' at the moving image only for 1/30 s or so, while you look at
> the static one for much longer.
>
> Just look at some of their examples to get an idea of what I'm talking about:
>
> http://www.antigrain.com/screenshots/index.html
>
> I've never seen any opengl-based antialiasing be of that quality. But
> there may be ways of achieving the same thing in OpenGL, I don't know
> (and to do so efficiently and portably, without requiring specific
> video cards).
>
> The other issue I recall is that the quality of openGL antialiasing is
> highly dependent on the video card and/or driver. While that may be
> OK for gamers, it's completely unacceptable IMO for scientific
> publication.
>
> > > > Compiling really sucks.
>
> Keep in mind that while python+cleverness can get you a lot of speed,
> there are operations that are *inescapably* slow in python's fully
> dynamic model today (without JIT-type tricks a la psyco that avoid
> dynamic dispatch in loops). Running a tight loop over a million
> elements of anything to do some repetitive operation will incur in
> Python's runtime check costs on every pass of the loop. In a plotting
> library, this type of computation is very frequent, and while some of
> it can be rolled into numpy-type array operations, that's not always
> possible. There's simply no way out (today) from compiled code for
> certain things in python, I'm afraid. Keep in mind that there are
> still people who regularly complain about MPL being *too slow* for
> their purposes, which involve interactive data exploration of enormous
> datasets. I'm sure that loss of speed would not be considered a
> desirable feature for a new MPL release by many :)
>
> I'm certainly hoping you guys can find some mechanism to join forces
> on this front, which I would absolutely love to see. But I just want
> to provide a bit of context as to why MPL uses extensions like Agg and
> relies on compiled code, which is I think a fairly critical need of
> the project.
>
> Having said all this, I'd be thrilled to be proven 100% wrong in all
> of the above, and to see a pure-python MPL that is as fast as today's
> and maintains the image quality we have today.
>
> One approach that has been thrown around in the past was to have an
> opengl based render while working interactively, that would force a
> re-render of the same entire scene via Agg for image saving. I don't
> know enough about the MPL internals to say how feasible this would be.
Hi Fernando!
what you said are valid points for matplotlib using Agg as a backend.
And as I said,
the default matplotlib installation should include it, no doubt about that.
On the other hand, I (and I think many other users) only need the super quality
only when saving the final plot. Of course, if it's worth the pain, I
can install the agg
backend and have the quality all the time, but many users will
sacrifice the quality,
if they can get at least some plot.
If it was just me, I use Debian, so for me using any C compiled code
is zero pain. But,
the majority of users of sympy, are probably windows users. (At least there are
more downloads of the windows installer, than the mulitplatform tarball). And
I am not sure compiling anything on windows is a pleasant experience
(honestly I
think forcing a user of sympy compiling something on windows is a show stopper).
Ondrej

On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote:
> > > * Agg (this could be optional)
> >
> > On the transforms branch, Agg is used for bezier curve realisation,
> > whether the Agg renderer is being used or not. This is used for things
> > like hit-testing and range-setting of path collections etc. This was
> > not fast enough in my earlier numpy-based implementation, since to take
> > advantage of numpy, you generally have to allocate lots of memory to
> > store the results in. In this particular case, each value can be
> > immediately thrown away, so all that extra work was unnecessary.
>
> So it's needed for path collections - what is that? When I want to do
> regular plots,
> like plotting some set of points, is that needed too? If not, it
> should be optional imho.
It's probably worth mentioning that one of the reasons John chose Agg
is because of image *quality* concerns. If I'm not mistaken (John and
A. Straw will correct me as needed), the OpenGL anti-aliasing quality
is positively horrible when you compare it to the quality of Agg.
Keep in mind that OpenGL is typically focused on keeping high
frame-rates for moving images, so pixel-perfect antialiasing is much
less of a concern for them, since your eye is a lot less likely to
notice such fine details (as long as there is *some* antialiasing).
For a static image, you tend to be a lot pickier, and Agg goes to
great lengths to ensure the best possible antialiasing quality. This
is part of the reason why normal television, at abysmally low
resolutions is still acceptable for viewing, while nobody would
consider a 400-line-image an acceptable photograph for most uses. You
'stare' at the moving image only for 1/30 s or so, while you look at
the static one for much longer.
Just look at some of their examples to get an idea of what I'm talking about:
http://www.antigrain.com/screenshots/index.html
I've never seen any opengl-based antialiasing be of that quality. But
there may be ways of achieving the same thing in OpenGL, I don't know
(and to do so efficiently and portably, without requiring specific
video cards).
The other issue I recall is that the quality of openGL antialiasing is
highly dependent on the video card and/or driver. While that may be
OK for gamers, it's completely unacceptable IMO for scientific
publication.
> > > Compiling really sucks.
Keep in mind that while python+cleverness can get you a lot of speed,
there are operations that are *inescapably* slow in python's fully
dynamic model today (without JIT-type tricks a la psyco that avoid
dynamic dispatch in loops). Running a tight loop over a million
elements of anything to do some repetitive operation will incur in
Python's runtime check costs on every pass of the loop. In a plotting
library, this type of computation is very frequent, and while some of
it can be rolled into numpy-type array operations, that's not always
possible. There's simply no way out (today) from compiled code for
certain things in python, I'm afraid. Keep in mind that there are
still people who regularly complain about MPL being *too slow* for
their purposes, which involve interactive data exploration of enormous
datasets. I'm sure that loss of speed would not be considered a
desirable feature for a new MPL release by many :)
I'm certainly hoping you guys can find some mechanism to join forces
on this front, which I would absolutely love to see. But I just want
to provide a bit of context as to why MPL uses extensions like Agg and
relies on compiled code, which is I think a fairly critical need of
the project.
Having said all this, I'd be thrilled to be proven 100% wrong in all
of the above, and to see a pure-python MPL that is as fast as today's
and maintains the image quality we have today.
One approach that has been thrown around in the past was to have an
opengl based render while working interactively, that would force a
re-render of the same entire scene via Agg for image saving. I don't
know enough about the MPL internals to say how feasible this would be.
Cheers,
f

On Jan 4, 2008 7:41 PM, Michael Droettboom <md...@st...> wrote:
> Ondrej Certik wrote:
> > * freetype (this could be rewritten using ctypes)
>
> I see that pyglet already has a freetype wrapper using ctypes -- it
> would be interesting to see if that could be used as a starting point.
> That could be used as a starting point. (Of course, ctypes is an
> external dependency before Python-2.5, which adds a dependency to
> matplotlib).
That is correct. I forgot about that. We do support python2.4 and it's
true that in order
for plotting to work, you need to install python-ctypes.
But python2.4 will hopefully get old soon, in favor of python2.5.
> I generally don't like ctypes-based wrappers since changes in the
> dependency can mean segfaults at runtime. I'm having a problem getting
> pyglet to work on my particular version of OpenGL, for instance. But
> perhaps freetype is stable enough for that not to be a problem.
Could you please report it to http://groups.google.com/group/pyglet-users ?
Alex (the author of pyglet) is really responsive. My own experience is
that it works out of the box.
> > * Agg (this could be optional)
>
> On the transforms branch, Agg is used for bezier curve realisation,
> whether the Agg renderer is being used or not. This is used for things
> like hit-testing and range-setting of path collections etc. This was
> not fast enough in my earlier numpy-based implementation, since to take
> advantage of numpy, you generally have to allocate lots of memory to
> store the results in. In this particular case, each value can be
> immediately thrown away, so all that extra work was unnecessary.
So it's needed for path collections - what is that? When I want to do
regular plots,
like plotting some set of points, is that needed too? If not, it
should be optional imho.
> > Compiling really sucks.
>
> Agreed. But there is a spectrum of suckage here. It also sucks to be
> unable to check that a call to some library that you don't provide
> (freetype) will succeed.
That sucks too. But I think there are mechanisms to check the exact version
of the library, aren't there?
> >>> Another cool stuff in matplotlib is the pure python latex renderer
> >>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
> >>> more info:
> >> Yes, the mathtext support in matplotlib is very nice, and Michael
> >> deserves the credit for taking from a package that
> >> works but has warts, to an extremely nice math layout engine using the
> >> Knuth algorithms. I'm sure others would like to use it without having
> >> to pull in all of matplotlib. With a ctypes freetype wrapper, it
> >> should be possible to build a free-standing mathtext.
> >
> > And this is really cool. I would like to have that. :)
> >
> > We'll try to help with that one.
>
> Great! I'll start by looking at pyglet's freetype wrapper and see how
> far I get.
Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
will answer any technical questions.
Ondrej

Ondrej Certik wrote:
> * freetype (this could be rewritten using ctypes)
I see that pyglet already has a freetype wrapper using ctypes -- it 
would be interesting to see if that could be used as a starting point. 
That could be used as a starting point. (Of course, ctypes is an 
external dependency before Python-2.5, which adds a dependency to 
matplotlib).
I generally don't like ctypes-based wrappers since changes in the 
dependency can mean segfaults at runtime. I'm having a problem getting 
pyglet to work on my particular version of OpenGL, for instance. But 
perhaps freetype is stable enough for that not to be a problem.
> * Agg (this could be optional)
On the transforms branch, Agg is used for bezier curve realisation, 
whether the Agg renderer is being used or not. This is used for things 
like hit-testing and range-setting of path collections etc. This was 
not fast enough in my earlier numpy-based implementation, since to take 
advantage of numpy, you generally have to allocate lots of memory to 
store the results in. In this particular case, each value can be 
immediately thrown away, so all that extra work was unnecessary.
> Compiling really sucks. 
Agreed. But there is a spectrum of suckage here. It also sucks to be 
unable to check that a call to some library that you don't provide 
(freetype) will succeed.
>>> Another cool stuff in matplotlib is the pure python latex renderer
>>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
>>> more info:
>> Yes, the mathtext support in matplotlib is very nice, and Michael
>> deserves the credit for taking from a package that
>> works but has warts, to an extremely nice math layout engine using the
>> Knuth algorithms. I'm sure others would like to use it without having
>> to pull in all of matplotlib. With a ctypes freetype wrapper, it
>> should be possible to build a free-standing mathtext.
> 
> And this is really cool. I would like to have that. :)
> 
> We'll try to help with that one.
Great! I'll start by looking at pyglet's freetype wrapper and see how 
far I get.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi Michael, John and Gael,
sorry for the later reply (holidays and stuff...)
On Jan 1, 2008 4:51 AM, Michael Droettboom <md...@st...> wrote:
> I'm off with family for the holidays, so my response will have to be somewhat
> brief.
>
> I'm excited about the ideas you bring up... I first heard about sympy at SciPy
> and was very impressed. Let's try to collaborate in any way possible. I know
> that "3D in matplotlib" already has some history of which I'm not aware, so I'll
> leave that for others to comment on.
>
> As for the C++ dependencies, Agg is a pretty strong one. Yes, it is possible to
> do rendering with Gtk or Wx alone, but it's not very pretty (no-aa). Gtk/Cairo is
> a good high-quality combination, but it (at least currently) leaves out all the
> other GUI frameworks, and is not BSD-like licensed. The other important
> C/C++ requirement is matplotlib's interface to freetype (FT2Font). That would
> be really painful to reimplement in pure Python -- freetype is a complex and
> mature piece of software. In the trunk, there is a required framework for
> transformations, and in the "transforms branch" there is a framework for
> polycurve manipulations, both of which are required to do any plotting. Those
> would have a major performance penalty going to Python, and even
> notwithstanding, are non-trivial bits of code to reimplement. Beyond that, there
> are utilities for contours and images etc., which are reasonably optional but
> people use all the time. In short, there's a not of C/C++ in the core of
> matplotlib -- maybe the time would be better spent resolving any build issues
> that make portability difficult...? I'm not sure it's realistic to expect matplotlib to
> be pure Python at this point without losing a lot of features, but I agree it would
> be nice...
I'll reply to this below.
> As for the mathtext Python math rendering engine, it isn't *really* pure Python.
> It relies on matplotlib's interface to Freetype. Ideally, it would be nice to have a
> general-purpose Python interface to freetype (I know the PyCairo folks are
> wanting such a thing), and then the mathtext engine could use that.
> Unfortunately, the existing freetype wrapper in matplotlib is very incomplete
> and pretty tied to matplotlib-specific ways of doing things. IMHO, you wouldn't
> really gain much by releasing FT2Font as a separate project unless it were
> generalized. I've sort of gone into a holding pattern, hoping someone else will
> release a Python freetype wrapper that matplotlib could use... Alternatively, the
> dependency on freetype could be removed by extracting and hardcoding all the
> font metrics from the math fonts into Python dictionaries etc. -- but then of
> course it would only work with a fixed set of fonts. This is what jsMath, (a
> pure-Javascript math rendering engine) does, for instance.
>
> With the exception of that issue, removing the mathtext engine from matplotlib
> should be possible, and I think it's a great idea. There are some matplotlib-
> specific bits mixed in there, but they should be reasonably straightforward to
> factor out. It already has support for rendering math to an in-memory image
> bitmap, which has been used for displaying math on GUI widgets, for example.
>
> Anyway -- cool ideas. Let's keep up the discussion.
>
> Cheers,
> Mike
>
On Jan 1, 2008 3:51 PM, John Hunter <jd...@gm...> wrote:
> On Dec 30, 2007 12:33 PM, Ondrej Certik <on...@ce...> wrote:
>
> > We should have gotten involved more in matplotlib development earlier,
> > but at least now. I think there should be just one 3D plotting
> > library in Python and imho matplotlib should do it. However, we need:
>
> Hi Ondrej,
>
> Sorry for the delay getting back to you. I've been on holiday so have
> only limited email access.
>
> > * it should be pure python
> > * fast and interactive 3D stuff
> > * needs to work out of the box on linux, mac os x, windows (without compilation)
>
> We have long wanted limited 3D capability in matplotlib, and as you
> know we have some functionality in the axes3d classes but it has
> proven to be extremely slow, and somewhat buggy, and the original
> author has moved on to other things so it is mostly unsupported. We
> would be very excited if there was some way to incorporate your work
> using pyglet, which is very nice.
>
> matplotlib started out life as pure python, and for several release
> cycles remained that way. A that time, there were two backends, GTK
> and PS, so there is no reason in principle that matplotlib needs to
> have extension code. Over time, we have evolved a considerable amount
> of extension code, which Michael outlined for you, but it generally
> falls into two classes:
>
> * access 3rd party C/C++ (Agg, freetype and libpng)
>
> * make matplotlib go faster (image, transforms, other helpers)
>
> A big chunk of extension code was removed in Michael's recent
> refactoring of transforms, and it is possible and desirable to remove
> more. Eg, we should be able to replace ft2font with a ctypes wrapper,
> though I have never experimented with this.
>
> While I think reducing the amount of extension code is useful and
> desirable, the complete eradication of it is unlikely, and would
> result in a matplotlib with limited functionality. Michael
> mentioned a few of these areas, but contouring and image support make
> heavy use of extension code that would be difficult to do in python.
> Also, we depend very heavily numpy, so even if matplotlib were pure
> python, it would depend on numpy which is not. And that dependency is
> at the core of matplotlib.
>
> I tend to agree with Michael: our effort would be better spent
> identifying the areas that make compilation problematic than trying to
> remove all extension code. For the most part, these difficulties
> arise from depending on 3rd party C/C+ code at compile time (eg a GUI
> toolkit or libpng or freetype). I would love to find a way to remove
> all these compile time dependencies.
All right, so to recapitulate. From the technical point of view, the
C/C++ dependency is
* numpy (this one will be hard to remove)
* image extension code (this could be maybe done using pyglet?)
* freetype (this could be rewritten using ctypes)
* libpng (this could be optional)
* Agg (this could be optional)
I understand, that from the matplotlib point of view, C/C++ depenency is fine.
But in sympy, we don't want to use C/C++ by default. SymPy is mainly
symbolic manipulation library. Everything else is nice, if it can be
done in pure python,
if it cannot, we'll not include it by default
Of course, users can use matplotlib externally and that's fine. But still
being able to do some graphing from sympy is very cool, because it's easy.
Ideal solution imho is this:
* the kernel of matplotlib is pure python, i.e. we can include it in sympy
* all the modules could be included by default in the matplotlib distribution,
but not in sympy
Compiling really sucks. I mean, I am not against C, we will probably include an
optional C module too for speeding up sympy, but not by default.
pyglet shows, that it is possible to do nice and fast 3D plots in pure python,
so we'll have that in sympy. But I would like to have solid 2D plotting too,
and I don't want to reinvent the wheel and split communities. We actually
already did that, by designing our own 3D plotting stuff, but that was
mainly to show, that this indeed is the way to go.
So, at least, we can try to include it in matplotlib. Unfortunately,
I don't have time for that, but I think you already have some ideas where
and how to do it. And I can help with any questions you might have.
But we'll try to help if it is possible to separate at least something
in pure python,
so that we can use it.
> > Another cool stuff in matplotlib is the pure python latex renderer
> > (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
> > more info:
>
> Yes, the mathtext support in matplotlib is very nice, and Michael
> deserves the credit for taking from a package that
> works but has warts, to an extremely nice math layout engine using the
> Knuth algorithms. I'm sure others would like to use it without having
> to pull in all of matplotlib. With a ctypes freetype wrapper, it
> should be possible to build a free-standing mathtext.
And this is really cool. I would like to have that. :)
We'll try to help with that one.
On Jan 4, 2008 3:48 AM, Gael Varoquaux <gae...@no...> wrote:
> On Mon, Dec 31, 2007 at 12:40:26AM +0100, Ondrej Certik wrote:
> > I think there should be just one 3D plotting
> > library in Python and imho matplotlib should do it. However, we need:
>
> > * it should be pure python
> > * fast and interactive 3D stuff
> > * needs to work out of the box on linux, mac os x, windows (without compilation)
>
> A long time ago I took a close look at adding powerful 3D features in
> gnuplot, namely povray exporting, but I found out that some core work was
> needed.
>
> What I think I learnt from this experience was that the core plotting
> engine couldn't share much code between the 2D and the 3D. I drew the
> conclusion that the 2D and 3D plotting packages should be different,
> eventhough, it might be interesting to connect together them as well as
> possible.
The 3D engine and everything is already done in SymPy.
Now the question is how and if to connect this with matplotlib.
I think all of us want that.
And also the other way round - get the 2D plotting from matplotlib
and use it in sympy.
> I also think that code reuse is very important, and that I don't want to
> write a rendered.
That is already done.
> This is why I set up on the endeaviour of modifying Mayavi2 to make it
> pylab-like. Prabhu has opened to way to the use of Mayavi2 solely as a
> library, and together we have worked on an API with a familiar syntax,
> and a light UI. There has been much progress, as I illustrate on a
> blogpost: http://gael-varoquaux.info/blog/?p=3
Yes, exactly.
> This does not answer you problem, as two of you requirements are not
> satisfied (namely because of the use of VTK). I have the feeling that you
> are looking for something simpler than what we are building. However this
> does not mean we cannot work together to try to make the APIs as similar
> as possible, and to make it easy to replace one library with another.
>
> By the way, mayavi2's requirement list is heavy, we have been told this
> more than once, but I consider some dependencies (namely traits and
> friends) to be core technology that many other projects would gain to
> use, moreover they are easy to build (althought packaging with eggs tends
> to confuse people). On the contrary, I fully admit VTK is a heavy
> dependency and that it would be an interesting project for an alternate
> library to provide part of the features without this dependency.
>
>
> I just got a message from Michael McKerns saying that the DANSE project
> are also working on a pylab-like API to VTK. We are planning to try and
> coordinnate our APIs.
>
> OK, I really must go to sleep now.
Right. Definitely at least the API should be the same.
But I still would like to use matplotlib, because many people use it
and are familiar with it. Sage uses it too.
As to the speed of python, I think, at least as far as sympy is
concerned, it's enough, if things are done cleverly. See my latest
post for that:
http://ondrejcertik.blogspot.com/2008/01/sympysympycore-pure-python-up-to-5x.html
And if 3D things can be done in pure python, 2D things can be too. And
if something can be done in pure python, it's fast enough,
then it should be done in python, rather than C. That's my logic. :)
Ondrej

The built-in mathtext support does not support "\underline" (and never 
did AFAICT).
It sounds like you had "text.usetex" turned on in your matplotlibrc, and 
now for some reason or other you don't.
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
> 
> I have some trouble with the following lines
> 
> title(r'$\underline{\lambda}_n$= '+str(f))
> plot(arange(0,len(data)),data,lw=2)
> xlabel('Iterations')
> ylabel('Largest eigenvalue')
> savefig('yuanlbl.png')
> 
> IIRC the code worked before the recent changes in
> svn. How can I resolve the problem ?
> 
> 
> Traceback (most recent call last):
> File "yuan2.py", line 84, in <module>
> savefig('yuanlbl.png')
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/pyplot.py", 
> line 269, in savefig
> return fig.savefig(*args, **kwargs)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", 
> line 782, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/backend_bases.py", 
> line 1195, in print_figure
> **kwargs)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 103, in print_png
> return agg.print_png(filename, *args, **kwargs)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 396, in print_png
> self.draw()
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 358, in draw
> self.figure.draw(self.renderer)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", 
> line 624, in draw
> for a in self.axes: a.draw(renderer)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/axes.py", 
> line 1345, in draw
> a.draw(renderer)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/text.py", 
> line 317, in draw
> bbox, info = self._get_layout(renderer)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/text.py", 
> line 201, in _get_layout
> line, self._fontproperties, 
> ismath=self.is_math_text(line))
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 233, in get_text_width_height_descent
> self.mathtext_parser.parse(s, self.dpi.get(), prop)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2729, in parse
> box = self._parser.parse(s, font_output, fontsize, 
> dpi)
> File 
> "/usr/local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2204, in parse
> str(err)]))
> ValueError:
> $\underline{\lambda}_n$= 443.75221866615522
> ^
> Expected end of text (at char 0), (line:1, col:1)
> 
> Nils
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I have some trouble with the following lines
title(r'$\underline{\lambda}_n$= '+str(f))
plot(arange(0,len(data)),data,lw=2)
xlabel('Iterations')
ylabel('Largest eigenvalue')
savefig('yuanlbl.png')
IIRC the code worked before the recent changes in
svn. How can I resolve the problem ?
Traceback (most recent call last):
 File "yuan2.py", line 84, in <module>
 savefig('yuanlbl.png')
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/pyplot.py", 
line 269, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", 
line 782, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1195, in print_figure
 **kwargs)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 103, in print_png
 return agg.print_png(filename, *args, **kwargs)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 396, in print_png
 self.draw()
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 358, in draw
 self.figure.draw(self.renderer)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", 
line 624, in draw
 for a in self.axes: a.draw(renderer)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/axes.py", 
line 1345, in draw
 a.draw(renderer)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/text.py", 
line 317, in draw
 bbox, info = self._get_layout(renderer)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/text.py", 
line 201, in _get_layout
 line, self._fontproperties, 
ismath=self.is_math_text(line))
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 233, in get_text_width_height_descent
 self.mathtext_parser.parse(s, self.dpi.get(), prop)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
line 2729, in parse
 box = self._parser.parse(s, font_output, fontsize, 
dpi)
 File 
"/usr/local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
line 2204, in parse
 str(err)]))
ValueError:
$\underline{\lambda}_n$= 443.75221866615522
^
Expected end of text (at char 0), (line:1, col:1)
>>>
Nils

I should have plenty of time on Sunday, so could we shoot for a freeze
before Sunday morning?
On Jan 4, 2008 10:03 AM, John Hunter <jd...@gm...> wrote:
> It looks like the trunk has stabilized with the important bugs fixed,
> so I think it would be a good time to push out the 0.91.2 release,
> perhaps Monday. Charlie, are you available for this? Does anyone
> have any reason to delay?
>
> Thanks,
> JDH
>

It looks like the trunk has stabilized with the important bugs fixed,
so I think it would be a good time to push out the 0.91.2 release,
perhaps Monday. Charlie, are you available for this? Does anyone
have any reason to delay?
Thanks,
JDH

On Mon, Dec 31, 2007 at 12:40:26AM +0100, Ondrej Certik wrote:
> I think there should be just one 3D plotting
> library in Python and imho matplotlib should do it. However, we need:
> * it should be pure python
> * fast and interactive 3D stuff
> * needs to work out of the box on linux, mac os x, windows (without compilation)
A long time ago I took a close look at adding powerful 3D features in
gnuplot, namely povray exporting, but I found out that some core work was
needed.
What I think I learnt from this experience was that the core plotting
engine couldn't share much code between the 2D and the 3D. I drew the
conclusion that the 2D and 3D plotting packages should be different,
eventhough, it might be interesting to connect together them as well as
possible.
I also think that code reuse is very important, and that I don't want to
write a rendered.
This is why I set up on the endeaviour of modifying Mayavi2 to make it
pylab-like. Prabhu has opened to way to the use of Mayavi2 solely as a
library, and together we have worked on an API with a familiar syntax,
and a light UI. There has been much progress, as I illustrate on a
blogpost: http://gael-varoquaux.info/blog/?p=3
This does not answer you problem, as two of you requirements are not
satisfied (namely because of the use of VTK). I have the feeling that you
are looking for something simpler than what we are building. However this
does not mean we cannot work together to try to make the APIs as similar
as possible, and to make it easy to replace one library with another.
By the way, mayavi2's requirement list is heavy, we have been told this
more than once, but I consider some dependencies (namely traits and
friends) to be core technology that many other projects would gain to
use, moreover they are easy to build (althought packaging with eggs tends
to confuse people). On the contrary, I fully admit VTK is a heavy
dependency and that it would be an interesting project for an alternate
library to provide part of the features without this dependency.
I just got a message from Michael McKerns saying that the DANSE project
are also working on a pylab-like API to VTK. We are planning to try and
coordinnate our APIs.
OK, I really must go to sleep now.
Gaël