Hi Michael, John and Gael, sorry for the later reply (holidays and stuff...)
On Jan 1, 2008 4:51 AM, Michael Droettboom <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On Dec 30, 2007 12:33 PM, Ondrej Certik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
