headers
Michael Droettboom | 1 Jan 04:51

Re: merging sympy plotting stuff with matplotlib

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...

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Hunter | 1 Jan 15:51
Picon
Gravatar

Re: merging sympy plotting stuff with matplotlib

On Dec 30, 2007 12:33 PM, Ondrej Certik <ondrej@...> 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)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gael Varoquaux | 4 Jan 03:48
Favicon
Gravatar

Re: merging sympy plotting stuff with matplotlib

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
(Continue reading)

Permalink | Reply | 17 comments |
headers
John Hunter | 4 Jan 16:03
Picon
Gravatar

0.91.2 release plans

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

-------------------------------------------------------------------------
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/
Permalink | Reply | 1 comment |
headers
Charlie Moad | 4 Jan 16:31
Picon

Re: 0.91.2 release plans

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 <jdh2358@...> 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
>

-------------------------------------------------------------------------
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/
Permalink | Reply | 0 comments |
headers
Nils Wagner | 4 Jan 17:05
Picon
Favicon

Trouble with mathtext.py

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",
(Continue reading)

Permalink | Reply | 501 comments |
headers
Michael Droettboom | 4 Jan 17:12

Re: Trouble with mathtext.py

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
(Continue reading)

Permalink | Reply | 501 comments |
headers
Ondrej Certik | 4 Jan 18:06
Picon
Gravatar

Re: merging sympy plotting stuff with matplotlib

Hi Michael, John and Gael,

sorry for the later reply (holidays and stuff...)

On Jan 1, 2008 4:51 AM, Michael Droettboom <mdroe@...> 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...
(Continue reading)

Permalink | Reply | 15 comments |
headers
Michael Droettboom | 4 Jan 19:41

Re: merging sympy plotting stuff with matplotlib

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.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Ondrej Certik | 4 Jan 19:55
Picon
Gravatar

Re: merging sympy plotting stuff with matplotlib

On Jan 4, 2008 7:41 PM, Michael Droettboom <mdroe@...> 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
(Continue reading)

Permalink | Reply | 13 comments |

Gmane