Hi, I saw that 3D plotting was dropped from matplotlib since the last time I used it. Unfortunately, it is pretty necessary for some of the work I am doing. Thus, I have started the process of refactoring the code to work with recent versions of matplotlib. Right now, it is still in very early stages and is quite flaky but I do have some functionality. In particular, I am able to do a regular 3d plot, a wireframe plot and a scatter plot. If this interests anyone I am making the code available via git. Instructions are available on my website at: http://jonathantaylor.ca/projects.shtml Feel free to send any patches my way. Best, Jon.
On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor < jon...@ut...> wrote: > Hi, > > I saw that 3D plotting was dropped from matplotlib since the last time > I used it. Unfortunately, it is pretty necessary for some of the work > I am doing. Thus, I have started the process of refactoring the code > to work with recent versions of matplotlib. > > Right now, it is still in very early stages and is quite flaky but I > do have some functionality. In particular, I am able to do a regular > 3d plot, a wireframe plot and a scatter plot. If this interests > anyone I am making the code available via git. Instructions are > available on my website at: > That's great -- a number of people were very disappointed to see the functionality removed, even though it was primitive compared to a good 3D toolkit. The problem was, we could never find a core developer who was interested in taking it under his wing. Once you get this to a satisfactory point, I suggest you develop it as an mpl toolkit. That way, it will get installed with every mpl distro (the plain vanilla toolkits we ship, the complex ones like basemap are distributed separately) but without the implicit promise of full support until someone is willing to step up and offer to fully support it. JDH
That sounds reasonable. Can I ask what it is that was primitive? Having looked through the code I see that a few shortcuts were made to minimize the amount of code written that makes it especially susceptible to changes in the 2D code. That said, it seems like it was comparable functionally to matlab's 3d plots, which is my goal for it. Best, Jon. P.S. I saw your talk at NIPS 2008 this year. I have used mpl for a while now but that demo where you url.opened() yahoo finance and plotted it with those nice dates in 2/3 lines was very nice. ;) On Tue, Mar 3, 2009 at 9:14 AM, John Hunter <jd...@gm...> wrote: > > > On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor > <jon...@ut...> wrote: >> >> Hi, >> >> I saw that 3D plotting was dropped from matplotlib since the last time >> I used it. Unfortunately, it is pretty necessary for some of the work >> I am doing. Thus, I have started the process of refactoring the code >> to work with recent versions of matplotlib. >> >> Right now, it is still in very early stages and is quite flaky but I >> do have some functionality. In particular, I am able to do a regular >> 3d plot, a wireframe plot and a scatter plot. If this interests >> anyone I am making the code available via git. Instructions are >> available on my website at: > > That's great -- a number of people were very disappointed to see the > functionality removed, even though it was primitive compared to a good 3D > toolkit. The problem was, we could never find a core developer who was > interested in taking it under his wing. Once you get this to a satisfactory > point, I suggest you develop it as an mpl toolkit. That way, it will get > installed with every mpl distro (the plain vanilla toolkits we ship, the > complex ones like basemap are distributed separately) but without the > implicit promise of full support until someone is willing to step up and > offer to fully support it. > > JDH > >
On Tue, Mar 3, 2009 at 9:56 AM, Jonathan Taylor <jon...@ut... > wrote: > That sounds reasonable. Can I ask what it is that was primitive? > Having looked through the code I see that a few shortcuts were made to > minimize the amount of code written that makes it especially > susceptible to changes in the 2D code. That said, it seems like it > was comparable functionally to matlab's 3d plots, which is my goal for > it. > Well, it is painfully slow, since it does everything in software, and there are some corner cases where the zorder clipping is broken in the presence of alpha transparency, and it doesn't do lighting, shadows, etc.... But it does do enough for basic stuff, so we would be happy if you could resurrect it cleanly enough for a toolkit. > > P.S. I saw your talk at NIPS 2008 this year. I have used mpl for a > while now but that demo where you url.opened() yahoo finance and > plotted it with those nice dates in 2/3 lines was very nice. ;) Yep, that is a favorite example of mine :-) I'm giving a talk at SIAM on Thursday, and I think I'll do this one again, time permitting. JDH
On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote: > Well, it is painfully slow, since it does everything in software, and there > are some corner cases where the zorder clipping is broken in the presence of > alpha transparency, and it doesn't do lighting, shadows, etc.... But it > does do enough for basic stuff, so we would be happy if you could resurrect > it cleanly enough for a toolkit. > I'd just like to add that having a *bare minimum* 3D capability in mpl is extremely useful to me -- i.e. being to visualize 3D data as a point cloud or a wireframe mesh. While teaching with python and doing numerical experiments in my research it's invaluable to be able to throw together a wholly non-publication quality 3D plot to get a quick idea of what's going on. I would imagine that others who use mpl professionally (and not necessarily only for public consumption) would agree on the value of maintaining this bare minimum even if there is no short- or medium-term expectation that it will develop into anything more sophisticated. Cheers, Rob
Hi all, I was also a bit disappointed about the fact that 3d plotting support was dropped. I'm happy to help out to get it going again, so here's a patch to get surface plotting working; I'm busy with the contour plots as well. (We might want to do some code refactoring as well when it's functional). Regards, Reinier On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley <rob...@gm...> wrote: > On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote: > >> Well, it is painfully slow, since it does everything in software, and there >> are some corner cases where the zorder clipping is broken in the presence of >> alpha transparency, and it doesn't do lighting, shadows, etc.... But it >> does do enough for basic stuff, so we would be happy if you could resurrect >> it cleanly enough for a toolkit. >> > > I'd just like to add that having a *bare minimum* 3D capability in mpl > is extremely useful to me -- i.e. being to visualize 3D data as a > point cloud or a wireframe mesh. While teaching with python and doing > numerical experiments in my research it's invaluable to be able to > throw together a wholly non-publication quality 3D plot to get a quick > idea of what's going on. I would imagine that others who use mpl > professionally (and not necessarily only for public consumption) would > agree on the value of maintaining this bare minimum even if there is > no short- or medium-term expectation that it will develop into > anything more sophisticated. > > Cheers, > Rob > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639
Great. I applied your patch and pushed it to the web repository. I agree, that some more serious refactoring might be good. I have been leaving comments throughout the code with my thoughts on this. Cheers, Jon. On Wed, Mar 4, 2009 at 4:53 AM, Reinier Heeres <re...@he...> wrote: > Hi all, > > I was also a bit disappointed about the fact that 3d plotting support > was dropped. I'm happy to help out to get it going again, so here's a > patch to get surface plotting working; I'm busy with the contour plots > as well. > (We might want to do some code refactoring as well when it's functional). > > Regards, > Reinier > > On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley <rob...@gm...> wrote: >> On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote: >> >>> Well, it is painfully slow, since it does everything in software, and there >>> are some corner cases where the zorder clipping is broken in the presence of >>> alpha transparency, and it doesn't do lighting, shadows, etc.... But it >>> does do enough for basic stuff, so we would be happy if you could resurrect >>> it cleanly enough for a toolkit. >>> >> >> I'd just like to add that having a *bare minimum* 3D capability in mpl >> is extremely useful to me -- i.e. being to visualize 3D data as a >> point cloud or a wireframe mesh. While teaching with python and doing >> numerical experiments in my research it's invaluable to be able to >> throw together a wholly non-publication quality 3D plot to get a quick >> idea of what's going on. I would imagine that others who use mpl >> professionally (and not necessarily only for public consumption) would >> agree on the value of maintaining this bare minimum even if there is >> no short- or medium-term expectation that it will develop into >> anything more sophisticated. >> >> Cheers, >> Rob >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a 600ドル discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
Hi, On Wed, Mar 4, 2009 at 11:38 AM, Jonathan Taylor <jon...@ut...> wrote: > Great. I applied your patch and pushed it to the web repository. > > I agree, that some more serious refactoring might be good. I have > been leaving comments throughout the code with my thoughts on this. John just pointed me to this thread, so I just wanted to mention that we have 3d plots in sympy, that are pure python and use pyglet, here are some examples and docs: http://wiki.sympy.org/wiki/Plotting_Module http://docs.sympy.org/modules/plotting.html and if anyone would be interested in taking the code and use it for some of the 3D stuff that you want to do, I would fully support it. Ideally, if any of you would take it and maintain it, so that we don't have to, it'd be really awesome. We would like to just concentrate on symbolic manipulation with sympy and leave all the plotting to matplotlib, or other packages, if needed. Let me know if you are interested, we can help with integrating it. Ondrej
On Thu, Mar 05, 2009 at 07:03:00PM +0100, Cohen-Tanugi Johann wrote: > Nevertheless, I hate to think of matplotlib sending people to mayavi2 each > time 3D plotting is needed. Basic functionalities built-in would still be > highly desirable. Absolutely. I think we need basic 3D plotting functionnality that work without any 3D rendering library, both for robustess and for simplicity. I used to think different, because I believe that this approach is bound to fail on anything but very simple problems (my experience with gnuplot :>). I fear people are going to try and pull too far the simple 3D implementation. Nevertheless, it would be great to have some 3D in matplotlib, for easier mixing of 2D and 3D (I do this with Mayavi2 by saving to a temporary file, loading the result with matplotlib's imread, and displaying it with an imshow -- ugly!), and to have backend-universal, robust, 3D plotting. Gaël
Hi, I've done some further refactoring of mplot3d: - Almost all of the test plotting functions work, except for test_bar2D. Filled contours are not perfect yet and need a bit more work. Try "python axes.py" with the attached files to see how it looks! - I removed the Wrap2D class, which was using private class members throughout. I replaced this approach with dynamically changing the class type for Artist objects (e.g. PolyCollection to Poly3DCollection). This is also a bit of voodoo, but I think in the end it results in a bit less code, which is also more readable. - Much more code could still be removed (and added again later if necessary) Regards, Reinier BTW: I think plugging sympy's plotting functionality into matplotlib would not be so easy! The mplot3d code is much better suited for this... On Thu, Mar 5, 2009 at 7:13 PM, Gael Varoquaux <gae...@no...> wrote: > On Thu, Mar 05, 2009 at 07:03:00PM +0100, Cohen-Tanugi Johann wrote: >> Nevertheless, I hate to think of matplotlib sending people to mayavi2 each >> time 3D plotting is needed. Basic functionalities built-in would still be >> highly desirable. > > Absolutely. I think we need basic 3D plotting functionnality that work > without any 3D rendering library, both for robustess and for simplicity. > > I used to think different, because I believe that this approach is bound > to fail on anything but very simple problems (my experience with gnuplot > :>). I fear people are going to try and pull too far the simple 3D > implementation. > > Nevertheless, it would be great to have some 3D in matplotlib, for easier > mixing of 2D and 3D (I do this with Mayavi2 by saving to a temporary > file, loading the result with matplotlib's imread, and displaying it with > an imshow -- ugly!), and to have backend-universal, robust, 3D plotting. > > Gaël > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639
Hi Reinier, Awesome. Those plots are making me smile! I also agree with your refactoring and have applied your patch to my git repository. I agree with you concerning the sympy plotting routines. I think what we have here is quite flexible and does a very good job of replicating the equivalent functionality of MATLAB. I think it would be a huge effort trying to make 2D plots and 3D plots look consistent if another approach was taken. Indeed, this is a desirable characteristic. In addition, the code is actually very short and easy to maintain. Given that matplotlib has had trouble maintaining 3D code in the past, it might not be a good idea to switch to a more complicated codebase. You should grab some of my more recent changes as I have added a few more fixes. Most importantly, if you reuse the same figure, the old event handlers will still attached preventing Axes objects from dieing and causing interactive manipulation of the plots to be very sluggish. Also, in terms of performance, I have found that switching to TkAgg from GTKAgg was helpful. Also, I think the original code from John Porter was under a BSD license. I am thinking of adding our names and the BSD license to the top of each file to protect it while its not officially part of matplotlib. What do you think? Best, Jonathan. On Sun, Mar 8, 2009 at 8:04 PM, Reinier Heeres <re...@he...> wrote: > Hi, > > I've done some further refactoring of mplot3d: > > - Almost all of the test plotting functions work, except for > test_bar2D. Filled contours are not perfect yet and need a bit more > work. Try "python axes.py" with the attached files to see how it > looks! > > - I removed the Wrap2D class, which was using private class members > throughout. I replaced this approach with dynamically changing the > class type for Artist objects (e.g. PolyCollection to > Poly3DCollection). This is also a bit of voodoo, but I think in the > end it results in a bit less code, which is also more readable. > > - Much more code could still be removed (and added again later if necessary) > > Regards, > Reinier > > BTW: I think plugging sympy's plotting functionality into matplotlib > would not be so easy! The mplot3d code is much better suited for > this... > > On Thu, Mar 5, 2009 at 7:13 PM, Gael Varoquaux > <gae...@no...> wrote: >> On Thu, Mar 05, 2009 at 07:03:00PM +0100, Cohen-Tanugi Johann wrote: >>> Nevertheless, I hate to think of matplotlib sending people to mayavi2 each >>> time 3D plotting is needed. Basic functionalities built-in would still be >>> highly desirable. >> >> Absolutely. I think we need basic 3D plotting functionnality that work >> without any 3D rendering library, both for robustess and for simplicity. >> >> I used to think different, because I believe that this approach is bound >> to fail on anything but very simple problems (my experience with gnuplot >> :>). I fear people are going to try and pull too far the simple 3D >> implementation. >> >> Nevertheless, it would be great to have some 3D in matplotlib, for easier >> mixing of 2D and 3D (I do this with Mayavi2 by saving to a temporary >> file, loading the result with matplotlib's imread, and displaying it with >> an imshow -- ugly!), and to have backend-universal, robust, 3D plotting. >> >> Gaël >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a 600ドル discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor <jon...@ut...> wrote: > Hi Reinier, > > Awesome. Those plots are making me smile! I also agree with your > refactoring and have applied your patch to my git repository. > > I agree with you concerning the sympy plotting routines. I think what > we have here is quite flexible and does a very good job of replicating > the equivalent functionality of MATLAB. I think it would be a huge > effort trying to make 2D plots and 3D plots look consistent if another > approach was taken. Indeed, this is a desirable characteristic. In > addition, the code is actually very short and easy to maintain. Given > that matplotlib has had trouble maintaining 3D code in the past, it > might not be a good idea to switch to a more complicated codebase. > > You should grab some of my more recent changes as I have added a few > more fixes. Most importantly, if you reuse the same figure, the old > event handlers will still attached preventing Axes objects from dieing > and causing interactive manipulation of the plots to be very sluggish. > Also, in terms of performance, I have found that switching to TkAgg > from GTKAgg was helpful. > > Also, I think the original code from John Porter was under a BSD > license. I am thinking of adding our names and the BSD license to the > top of each file to protect it while its not officially part of > matplotlib. What do you think? A trivial patch is attached to make proj3d.py work. I tried the examples and it looks great. However, it's pretty slow, at least on my machine. The plotting in sympy is much faster. Is there some way to make the mplot3d faster? Ondrej
Hi, Thanks for the patch. How slow is it for you? I find it slow but quite usable. The main problem, I imagine, is that sympy is using OpenGL and thus your graphics card performs all the 3d -> 2d rendering whereas we do much of this in python/numpy. When I get a chance I am going to see if I can somewhat speed some of it up by adding an optional module to perform a few of these operations in C. Jon. On Sun, Mar 8, 2009 at 11:37 PM, Ondrej Certik <on...@ce...> wrote: > On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor > <jon...@ut...> wrote: >> Hi Reinier, >> >> Awesome. Those plots are making me smile! I also agree with your >> refactoring and have applied your patch to my git repository. >> >> I agree with you concerning the sympy plotting routines. I think what >> we have here is quite flexible and does a very good job of replicating >> the equivalent functionality of MATLAB. I think it would be a huge >> effort trying to make 2D plots and 3D plots look consistent if another >> approach was taken. Indeed, this is a desirable characteristic. In >> addition, the code is actually very short and easy to maintain. Given >> that matplotlib has had trouble maintaining 3D code in the past, it >> might not be a good idea to switch to a more complicated codebase. >> >> You should grab some of my more recent changes as I have added a few >> more fixes. Most importantly, if you reuse the same figure, the old >> event handlers will still attached preventing Axes objects from dieing >> and causing interactive manipulation of the plots to be very sluggish. >> Also, in terms of performance, I have found that switching to TkAgg >> from GTKAgg was helpful. >> >> Also, I think the original code from John Porter was under a BSD >> license. I am thinking of adding our names and the BSD license to the >> top of each file to protect it while its not officially part of >> matplotlib. What do you think? > > A trivial patch is attached to make proj3d.py work. > > I tried the examples and it looks great. However, it's pretty slow, at > least on my machine. The plotting in sympy is much faster. Is there > some way to make the mplot3d faster? > > Ondrej >
On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor <jon...@ut...> wrote: > Hi, > > Thanks for the patch. How slow is it for you? I find it slow but Well, when I use mouse to rotate the image, I can see that it lags behind. > quite usable. The main problem, I imagine, is that sympy is using > OpenGL and thus your graphics card performs all the 3d -> 2d rendering > whereas we do much of this in python/numpy. When I get a chance I am > going to see if I can somewhat speed some of it up by adding an > optional module to perform a few of these operations in C. Why not to use OpenGL as well? Ondrej
Just because we are using all the 2D drawing code to make the plots, which is why the 3d code is so small, maintainable and is visually consistent with 2D matplotlib. I believe that moving to OpenGL would require a substantial effort. J On Mon, Mar 9, 2009 at 12:17 AM, Ondrej Certik <on...@ce...> wrote: > On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor > <jon...@ut...> wrote: >> Hi, >> >> Thanks for the patch. How slow is it for you? I find it slow but > > Well, when I use mouse to rotate the image, I can see that it lags behind. > >> quite usable. The main problem, I imagine, is that sympy is using >> OpenGL and thus your graphics card performs all the 3d -> 2d rendering >> whereas we do much of this in python/numpy. When I get a chance I am >> going to see if I can somewhat speed some of it up by adding an >> optional module to perform a few of these operations in C. > > Why not to use OpenGL as well? > > Ondrej >
I posted only to you by a mistake -- can I reply to the list? On Mon, Mar 9, 2009 at 2:20 PM, Jonathan Taylor <jon...@ut...> wrote: > I think that it would be a little bit more complicated than that. I > believe that the current backends act as a canvas that you paint onto. > I do not think an OpenGL "canvas" would give us a big speed > improvement. In order to get the speed improvement, the "canvas" > would have to be 3D and the M3D code would paint into this 3D space > and let OpenGL (and your video card) worry about rendering it. I > think that it would be hard to make what came out of this process look > like what we have now. Perhaps it would be possible using > orthographic projection. > > Again, for simplicity, I am interested to see how much mileage we can > get out of our current implementation, perhaps by rewriting a few of > the algebraic routines in cython. Ok, I think I understand now and your approach seems reasonable to me. I can use mayavi if I need some fast and fancy stuff and one can use mpl if one just wants some regular 3d stuff. So what do you think we should do with our 3d plots in sympy? It's too simple for mayavi, too complex for mpl,... Well. :) Ondrje
On Mon, Mar 9, 2009 at 2:34 PM, Ondrej Certik <on...@ce...> wrote: > I posted only to you by a mistake -- can I reply to the list? Oops, I posted to the list by mistake too -- sorry about it. Anyway, here is the email that I sent to Jonathan only by a mistake: On Sun, Mar 8, 2009 at 9:44 PM, Jonathan Taylor <jon...@ut...> wrote: > Just because we are using all the 2D drawing code to make the plots, > which is why the 3d code is so small, maintainable and is visually > consistent with 2D matplotlib. I believe that moving to OpenGL would > require a substantial effort. Ok, now I understand the motivation. So if one wanted to go the OpenGL route, it would have to be created as a matplotlib backend? Then the 3D plots would be fast enough. Ondrej and he replied in my previous email, that I just wanted to ask if I can post to the list. Ondrej
Sure, I thought it was going to the list too ;) So no problem. I am not sure what you can do with that module. It seems a shame to waste. Perhaps it should be split out into a seperate 3d only plotting library that cares less about being matplotlib'ish than something packaged with MPL would. What do you think? Jon. On Mon, Mar 9, 2009 at 5:36 PM, Ondrej Certik <on...@ce...> wrote: > On Mon, Mar 9, 2009 at 2:34 PM, Ondrej Certik <on...@ce...> wrote: >> I posted only to you by a mistake -- can I reply to the list? > > Oops, I posted to the list by mistake too -- sorry about it. Anyway, > here is the email that I sent to Jonathan only by a mistake: > > On Sun, Mar 8, 2009 at 9:44 PM, Jonathan Taylor > <jon...@ut...> wrote: >> Just because we are using all the 2D drawing code to make the plots, >> which is why the 3d code is so small, maintainable and is visually >> consistent with 2D matplotlib. I believe that moving to OpenGL would >> require a substantial effort. > > Ok, now I understand the motivation. So if one wanted to go the OpenGL > route, it would have to be created as a matplotlib backend? Then the > 3D plots would be fast enough. > > Ondrej > > > > and he replied in my previous email, that I just wanted to ask if I > can post to the list. > > Ondrej >
On Mon, Mar 9, 2009 at 2:39 PM, Jonathan Taylor <jon...@ut...> wrote: > Sure, I thought it was going to the list too ;) So no problem. > > I am not sure what you can do with that module. It seems a shame to > waste. Perhaps it should be split out into a seperate 3d only > plotting library that cares less about being matplotlib'ish than > something packaged with MPL would. What do you think? Yes, we could do that. The problem is that I don't have time to maintain plotting stuff, so I need to find ways to attract someone else to take over it. :) So maybe creating some optional addon to matplotlib, as you say, could attract people's attantion. Ondrej
Hi, I updated my patch a bit more, and now all tests are running (try "python axes3d.py"). Only the contourf3D is not working correctly yet, but I'm sure it's fixable soon. There are also some obvious bugs (e.g. the semi-3D histograms are not depth-sorted). Anyway, I have applied the commit in a different git repo that also has gitweb.cgi for viewing: http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary Jon, I got rid of the spurious commit-and-revert entries but included your latest commits; perhaps you can clone from this tree now? Although I've not had a close look at the BSD license it definitely sounds like a good idea to add it if it applies to the original code. Shall we try to work to some sort of easily-installable form of the again-working code? Regards, Reinier On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor <jon...@ut...> wrote: > Hi Reinier, > > Awesome. Those plots are making me smile! I also agree with your > refactoring and have applied your patch to my git repository. > > I agree with you concerning the sympy plotting routines. I think what > we have here is quite flexible and does a very good job of replicating > the equivalent functionality of MATLAB. I think it would be a huge > effort trying to make 2D plots and 3D plots look consistent if another > approach was taken. Indeed, this is a desirable characteristic. In > addition, the code is actually very short and easy to maintain. Given > that matplotlib has had trouble maintaining 3D code in the past, it > might not be a good idea to switch to a more complicated codebase. > > You should grab some of my more recent changes as I have added a few > more fixes. Most importantly, if you reuse the same figure, the old > event handlers will still attached preventing Axes objects from dieing > and causing interactive manipulation of the plots to be very sluggish. > Also, in terms of performance, I have found that switching to TkAgg > from GTKAgg was helpful. > > Also, I think the original code from John Porter was under a BSD > license. I am thinking of adding our names and the BSD license to the > top of each file to protect it while its not officially part of > matplotlib. What do you think? > > Best, > Jonathan. -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639
Hi, that is great! Can you give me a git repository address to pull from? I can't from the web viewer. Thanks, J. On Wed, Mar 11, 2009 at 4:25 AM, Reinier Heeres <re...@he...> wrote: > Hi, > > I updated my patch a bit more, and now all tests are running (try > "python axes3d.py"). Only the contourf3D is not working correctly yet, > but I'm sure it's fixable soon. There are also some obvious bugs (e.g. > the semi-3D histograms are not depth-sorted). > > Anyway, I have applied the commit in a different git repo that also > has gitweb.cgi for viewing: > http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary > > Jon, I got rid of the spurious commit-and-revert entries but included > your latest commits; perhaps you can clone from this tree now? > > Although I've not had a close look at the BSD license it definitely > sounds like a good idea to add it if it applies to the original code. > Shall we try to work to some sort of easily-installable form of the > again-working code? > > Regards, > Reinier > > On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor > <jon...@ut...> wrote: >> Hi Reinier, >> >> Awesome. Those plots are making me smile! I also agree with your >> refactoring and have applied your patch to my git repository. >> >> I agree with you concerning the sympy plotting routines. I think what >> we have here is quite flexible and does a very good job of replicating >> the equivalent functionality of MATLAB. I think it would be a huge >> effort trying to make 2D plots and 3D plots look consistent if another >> approach was taken. Indeed, this is a desirable characteristic. In >> addition, the code is actually very short and easy to maintain. Given >> that matplotlib has had trouble maintaining 3D code in the past, it >> might not be a good idea to switch to a more complicated codebase. >> >> You should grab some of my more recent changes as I have added a few >> more fixes. Most importantly, if you reuse the same figure, the old >> event handlers will still attached preventing Axes objects from dieing >> and causing interactive manipulation of the plots to be very sluggish. >> Also, in terms of performance, I have found that switching to TkAgg >> from GTKAgg was helpful. >> >> Also, I think the original code from John Porter was under a BSD >> license. I am thinking of adding our names and the BSD license to the >> top of each file to protect it while its not officially part of >> matplotlib. What do you think? >> >> Best, >> Jonathan. > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Wed, Mar 11, 2009 at 3:25 AM, Reinier Heeres <re...@he...> wrote: > Hi, > > I updated my patch a bit more, and now all tests are running (try > "python axes3d.py"). Only the contourf3D is not working correctly yet, > but I'm sure it's fixable soon. There are also some obvious bugs (e.g. > the semi-3D histograms are not depth-sorted). > > Anyway, I have applied the commit in a different git repo that also > has gitweb.cgi for viewing: > > http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary > > Jon, I got rid of the spurious commit-and-revert entries but included > your latest commits; perhaps you can clone from this tree now? > > Although I've not had a close look at the BSD license it definitely > sounds like a good idea to add it if it applies to the original code. > Shall we try to work to some sort of easily-installable form of the > again-working code? One thing you can do is send a patch against lib/mpl-toolkits and I'll apply it to svn trunk. I was briefly scrolling through the recent diffs on art3d, and noticed + try: + zs = float(zs) + zs = [zs for i in range(len(paths))] + except: + pass Except in very special cases, we do not allow blanket excepts -- eg you should catch explicitly the error you are trying to trap. Also, it is usually better to try just the part you are trying to catch and then do the rest in an else. So if you are trying to catch the case where zs is not a float try: zs = float(zs) except TypeError: pass else: zs = [zs for i in range(len(paths))] Also, again I am not excatly sure what you are trying to do here, mpl has "duck typing" helpers to test whether something is iterable or num-like. So you can do import matplotlib.cbook as cbook if not cbook.iterable(zs): zs =float(zs) zs = [zs for i in range(len(paths))] Anyway -- great work so far. I'm having trouble making a git co work so I am looking forward to testing this when you have a snapshot or svn diff. JDH
Hi John, You should be able to check out a copy from my git repo via git clone http://jonathantaylor.ca/mplot3d.git cd mplot3d git pull I am missing Reiniers final update though but you should be able to run demo.py and the first few examples in the __name__ == '__main__' clause of axes3d.py. Best, J. On Wed, Mar 11, 2009 at 2:21 PM, John Hunter <jd...@gm...> wrote: > > > On Wed, Mar 11, 2009 at 3:25 AM, Reinier Heeres <re...@he...> wrote: >> >> Hi, >> >> I updated my patch a bit more, and now all tests are running (try >> "python axes3d.py"). Only the contourf3D is not working correctly yet, >> but I'm sure it's fixable soon. There are also some obvious bugs (e.g. >> the semi-3D histograms are not depth-sorted). >> >> Anyway, I have applied the commit in a different git repo that also >> has gitweb.cgi for viewing: >> >> http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary >> >> Jon, I got rid of the spurious commit-and-revert entries but included >> your latest commits; perhaps you can clone from this tree now? >> >> Although I've not had a close look at the BSD license it definitely >> sounds like a good idea to add it if it applies to the original code. >> Shall we try to work to some sort of easily-installable form of the >> again-working code? > > One thing you can do is send a patch against lib/mpl-toolkits and I'll apply > it to svn trunk. > > I was briefly scrolling through the recent diffs on art3d, and noticed > > + try: > + zs = float(zs) > + zs = [zs for i in range(len(paths))] > + except: > + pass > > Except in very special cases, we do not allow blanket excepts -- eg you > should catch explicitly the error you are trying to trap. Also, it is > usually better to try just the part you are trying to catch and then do the > rest in an else. So if you are trying to catch the case where zs is not a > float > > try: > zs = float(zs) > except TypeError: > pass > else: > zs = [zs for i in range(len(paths))] > > > Also, again I am not excatly sure what you are trying to do here, mpl has > "duck typing" helpers to test whether something is iterable or num-like. So > you can do > > > import matplotlib.cbook as cbook > if not cbook.iterable(zs): > zs =float(zs) > zs = [zs for i in range(len(paths))] > > Anyway -- great work so far. I'm having trouble making a git co work so I > am looking forward to testing this when you have a snapshot or svn diff. > > JDH > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
a On Wed, Mar 11, 2009 at 1:29 PM, Jonathan Taylor < jon...@ut...> wrote: > Hi John, > > You should be able to check out a copy from my git repo via > > git clone http://jonathantaylor.ca/mplot3d.git > cd mplot3d > git pull OK thanks. Just a word of warning. It appears you are developing against an older version of mpl (0.98?). For example, matplotlib.text.TextWithDash used in axis3d has been removed from svn HEAD. The attribute self._autoscaleon in axes3d is no longer available (use self.get_autoscale_on()) As soon as feasible, I suggest getting a svn co of mpl HEAD and working with that, to speed integration with the main line. You could resurrect TextWithDash internally for mplot3d if you want, but we found it difficult to maintain. JDH
Hi Jon, Good point, I forgot about that! It's available for cloning now: git clone http://qtwork.nano.tudelft.nl/public_git/users/rwh/mplot3d Cheers, Reinier On Wed, Mar 11, 2009 at 6:43 PM, Jonathan Taylor <jon...@ut...> wrote: > Hi, that is great! Can you give me a git repository address to pull > from? I can't from the web viewer. > > Thanks, > J. > > On Wed, Mar 11, 2009 at 4:25 AM, Reinier Heeres <re...@he...> wrote: >> Hi, >> >> I updated my patch a bit more, and now all tests are running (try >> "python axes3d.py"). Only the contourf3D is not working correctly yet, >> but I'm sure it's fixable soon. There are also some obvious bugs (e.g. >> the semi-3D histograms are not depth-sorted). >> >> Anyway, I have applied the commit in a different git repo that also >> has gitweb.cgi for viewing: >> http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary >> >> Jon, I got rid of the spurious commit-and-revert entries but included >> your latest commits; perhaps you can clone from this tree now? >> >> Although I've not had a close look at the BSD license it definitely >> sounds like a good idea to add it if it applies to the original code. >> Shall we try to work to some sort of easily-installable form of the >> again-working code? >> >> Regards, >> Reinier >> >> On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor >> <jon...@ut...> wrote: >>> Hi Reinier, >>> >>> Awesome. Those plots are making me smile! I also agree with your >>> refactoring and have applied your patch to my git repository. >>> >>> I agree with you concerning the sympy plotting routines. I think what >>> we have here is quite flexible and does a very good job of replicating >>> the equivalent functionality of MATLAB. I think it would be a huge >>> effort trying to make 2D plots and 3D plots look consistent if another >>> approach was taken. Indeed, this is a desirable characteristic. In >>> addition, the code is actually very short and easy to maintain. Given >>> that matplotlib has had trouble maintaining 3D code in the past, it >>> might not be a good idea to switch to a more complicated codebase. >>> >>> You should grab some of my more recent changes as I have added a few >>> more fixes. Most importantly, if you reuse the same figure, the old >>> event handlers will still attached preventing Axes objects from dieing >>> and causing interactive manipulation of the plots to be very sluggish. >>> Also, in terms of performance, I have found that switching to TkAgg >>> from GTKAgg was helpful. >>> >>> Also, I think the original code from John Porter was under a BSD >>> license. I am thinking of adding our names and the BSD license to the >>> top of each file to protect it while its not officially part of >>> matplotlib. What do you think? >>> >>> Best, >>> Jonathan. >> >> -- >> Reinier Heeres -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639