Hi all, I reworked the code in axis3d so that the XYZ-planes are always behind the object you're plotting. I also updated the label/ticks drawing a bit and dropped a lot of unnecessary code. I pushed it to my git repo at http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary Regards, Reinier On Wed, Mar 11, 2009 at 11:22 PM, Reinier Heeres <re...@he...> wrote: > 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 -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639
On Thu, Mar 5, 2009 at 10:39 AM, Ondrej Certik <on...@ce...> wrote: >> OK, but it wasn't clear from the example that I could plot a 3D array >> of arbitrary data points. The way that you put together the demo plots > > As I understand it, it plots triangles and/or wireframe in the end. > Currently I think our plotting mainly works with surfaces. How can you > plot a 3D array of arbitrary data points? E.g., by plotting a dot at the coordinate (x,y,z). > You need to convert it to > some triangles first, e.g. do you want to plot contours (isosurfaces)? > Or do you want to cut a plane in your 3D data points and plot that > plane? > If I have a set of scalar sample data on a rectangular 2D mesh that I want to plot in the 3D I'd want a simple wireframe rectangular surface plot. Can it do that? -Rob
On Thu, Mar 5, 2009 at 11:44 AM, Rob Clewley <rob...@gm...> wrote: > On Thu, Mar 5, 2009 at 10:39 AM, Ondrej Certik <on...@ce...> wrote: > >>> OK, but it wasn't clear from the example that I could plot a 3D array >>> of arbitrary data points. The way that you put together the demo plots >> >> As I understand it, it plots triangles and/or wireframe in the end. >> Currently I think our plotting mainly works with surfaces. How can you >> plot a 3D array of arbitrary data points? > > E.g., by plotting a dot at the coordinate (x,y,z). I guess more like a small ball in opengl. I think this can be done directly in pyglet. > >> You need to convert it to >> some triangles first, e.g. do you want to plot contours (isosurfaces)? >> Or do you want to cut a plane in your 3D data points and plot that >> plane? >> > > If I have a set of scalar sample data on a rectangular 2D mesh that I > want to plot in the 3D I'd want a simple wireframe rectangular surface > plot. Can it do that? Yes, that can be done. I can post a simple example, but right now I am urgently working on getting mayavi2 working in the offline mode in the Sage notebook for my presentation on Friday, so I'll get back to this later. Ondrej
On Thu, Mar 05, 2009 at 11:44:16AM -0500, Rob Clewley wrote: > If I have a set of scalar sample data on a rectangular 2D mesh that I > want to plot in the 3D I'd want a simple wireframe rectangular surface > plot. Can it do that? My experience from trying to design a simple API to do simple 3D plotting of data stored as numpy array is that everybody has his own usecase (that he often believes is universal and obvious), and that designing an API to make a particular usecase simple is easy, but keeping reasonnably versatile and powerful API while making it easy to use for all the 'simple' usecases is terribly hard. That said, Mayavi2 is incredibly powerful and with time (thanks to feedback from users) we are getting better at having a simple and powerful API, and a documentation that tries to 'solve your problem'. I know Mayavi2 has its problems (mainly difficult to instal because of historical reasons, and big dependencies), but for non trivial 3D plotting problems, especially with large datasets, keep it in mind. (It also works well for trivial problems, it is just that if it is not packaged, I understand that the hassle of installing it may be higher than the gain of using it). By the way, I am happy to take feedback on any problems with Mayavi2 (I am not pretending I will solve them :>). I believe that we have made huge progress in usability recently, and that it is no longer a monster hard to master and useless for simple problems, but I may be mistaken. Cheers, Gaël
wouaouh..... if I had known that sumpy had this functionality, I would have downloaded it ages ago. This is a good example of justified 'taylorisation', IMHO. Big +1 on seing this moved from sympy to matplotlib. I am not expert at coding guis et al, but if you need reviewers/testers or doc writers, I will be happy to give a hand (even two). best, Johann Ondrej Certik wrote: > 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 > > ------------------------------------------------------------------------------ > 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 Thu, Mar 5, 2009 at 5:14 AM, Johann Cohen-Tanugi <co...@sl...> wrote: > wouaouh..... if I had known that sumpy had this functionality, I would > have downloaded it ages ago. This is a good example of justified > 'taylorisation', IMHO. > Big +1 on seing this moved from sympy to matplotlib. I am not expert at > coding guis et al, but if you need reviewers/testers or doc writers, I > will be happy to give a hand (even two). > best, > Johann Yes, I didn't know that either. But it's not clear if I can plot discrete data using this interface - at least the examples on the wiki make it look that way. I'm also +1 on seeing it moved into mpl, but I don't know if the APIs and dependencies are too dissimilar to make it work.
On Thu, Mar 5, 2009 at 10:02 AM, Rob Clewley <rob...@gm...> wrote: > On Thu, Mar 5, 2009 at 5:14 AM, Johann Cohen-Tanugi > <co...@sl...> wrote: >> wouaouh..... if I had known that sumpy had this functionality, I would >> have downloaded it ages ago. This is a good example of justified >> 'taylorisation', IMHO. >> Big +1 on seing this moved from sympy to matplotlib. I am not expert at >> coding guis et al, but if you need reviewers/testers or doc writers, I >> will be happy to give a hand (even two). >> best, >> Johann > > Yes, I didn't know that either. But it's not clear if I can plot > discrete data using this interface - at least the examples on the wiki I am not sure if I understand your question, but It only plots discrete data --- it takes some sympy expression, evaluates it on a discrete grid and plots it. So you would just take the plotting stuff. > make it look that way. I'm also +1 on seeing it moved into mpl, but I > don't know if the APIs and dependencies are too dissimilar to make it > work. There are no dependencies besides pyglet (e.g. it does not depend on sympy, or if it does, it can be trivially fixed). As to the API, just look into sympy/plotting. And play with the 3D plots in sympy to see how it looks like and how fast/slow it is (I think it's pretty fast). Then you will have to decide, if it's easier for you to implement something from scratch, or take our stuff. As I said, I would love if mpl has similar capability, so that we can get rid of this from sympy. If you decide to go this way, I (and other sympy developers) will be at hand to help you integrate it. Ondrej
>> Yes, I didn't know that either. But it's not clear if I can plot >> discrete data using this interface - at least the examples on the wiki > > I am not sure if I understand your question, but It only plots > discrete data --- it takes some sympy expression, evaluates it on a > discrete grid and plots it. So you would just take the plotting stuff. OK, but it wasn't clear from the example that I could plot a 3D array of arbitrary data points. The way that you put together the demo plots involved a symbolic function that would be called to generate the points. Maybe you could add an example that plots some arbitrary data that has been imported from a text file? >> make it look that way. I'm also +1 on seeing it moved into mpl, but I >> don't know if the APIs and dependencies are too dissimilar to make it >> work. > > There are no dependencies besides pyglet (e.g. it does not depend on > sympy, or if it does, it can be trivially fixed). Well, I meant more like is there a design dependency that is incompatible with mpl. I'll shut up now because I know zilch about mpl's internals!
On Thu, Mar 5, 2009 at 10:15 AM, Rob Clewley <rob...@gm...> wrote: >>> Yes, I didn't know that either. But it's not clear if I can plot >>> discrete data using this interface - at least the examples on the wiki >> >> I am not sure if I understand your question, but It only plots >> discrete data --- it takes some sympy expression, evaluates it on a >> discrete grid and plots it. So you would just take the plotting stuff. > > OK, but it wasn't clear from the example that I could plot a 3D array > of arbitrary data points. The way that you put together the demo plots As I understand it, it plots triangles and/or wireframe in the end. Currently I think our plotting mainly works with surfaces. How can you plot a 3D array of arbitrary data points? You need to convert it to some triangles first, e.g. do you want to plot contours (isosurfaces)? Or do you want to cut a plane in your 3D data points and plot that plane? > involved a symbolic function that would be called to generate the > points. Maybe you could add an example that plots some arbitrary data > that has been imported from a text file? > >>> make it look that way. I'm also +1 on seeing it moved into mpl, but I >>> don't know if the APIs and dependencies are too dissimilar to make it >>> work. >> >> There are no dependencies besides pyglet (e.g. it does not depend on >> sympy, or if it does, it can be trivially fixed). > > Well, I meant more like is there a design dependency that is > incompatible with mpl. I'll shut up now because I know zilch about > mpl's internals! The best thing is to just look into our sources, it's pretty well documented. Ondrej
Hi,
I think that except for contourf3D everything is functioning fine
again, so I'm thinking about packaging/distributing it. (I will try to
fix contourf3D as well when I can find some time)
2009年3月3日 John Hunter <jd...@gm...>:
>
>
> 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 good. I assume you mean adding it to lib/mpl_toolkits in
the matplotlib source? It would be great to do this soon.
I also tried to create a separate mpl_toolkit installer with
setuptools, but can't get that to work properly:
In [2]: import mpl_toolkits.mplot3d
/usr/lib/python2.5/site-packages/mpl_toolkits/__init__.py:2:
UserWarning: Module mpl_toolkits was already imported from
/usr/lib/python2.5/site-packages/mpl_toolkits/__init__.pyc, but
/usr/lib/python2.5/site-packages/mplot3d-0.1-py2.5.egg is being added
to sys.path
__import__('pkg_resources').declare_namespace(__name__)
This can probably be fixed, but I would prefer things to live in the
matplotlib tree, and I'm willing to volunteer to support it.
Cheers,
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639
On Mon, Mar 30, 2009 at 2:13 AM, Reinier Heeres <re...@he...> wrote:
>
> That sounds good. I assume you mean adding it to lib/mpl_toolkits in
> the matplotlib source? It would be great to do this soon.
>
> I also tried to create a separate mpl_toolkit installer with
> setuptools, but can't get that to work properly:
>
> In [2]: import mpl_toolkits.mplot3d
> /usr/lib/python2.5/site-packages/mpl_toolkits/__init__.py:2:
> UserWarning: Module mpl_toolkits was already imported from
> /usr/lib/python2.5/site-packages/mpl_toolkits/__init__.pyc, but
> /usr/lib/python2.5/site-packages/mplot3d-0.1-py2.5.egg is being added
> to sys.path
> __import__('pkg_resources').declare_namespace(__name__)
>
> This can probably be fixed, but I would prefer things to live in the
> matplotlib tree, and I'm willing to volunteer to support it.
>
Since this is pure python, my plan was to put it in the mpl source tree in
mpl_toolkits so that it gets included in all mpl installs, rather than
distribute it separately. This might put some additional burden on you
since we still use svn, but we have some notes on developing mpl via git
with a git/svn gateway
http://matplotlib.sourceforge.net/devel/coding_guide.html#id3
Have you done any work on bringing it up to compatibility with svn HEAD?
I'd like at least the basic demos to work with svn HEAD before I do the
import. I think the major missing piece there is the missing TextWithDash.
Thanks,
JDH
Hey Reiner -- please make sure you "reply-to-all" so others can participate in the thread. I'm am CC-ing the reply to the list. On Wed, Apr 1, 2009 at 5:19 PM, Reinier Heeres <re...@he...> wrote: > That is one issue, but if I try to solve that I get some > strange-looking result. It seems that the patches I am drawing are not > scaled properly; they are way too large. Do you know of any obvious > change that might have resulted in this (I guess it might be in the > "transform" parts)? And is there perhaps a nice web-interface to > compare different versions of various files? What version of mpl are you using? The major transform work was done between 0.91 and 0.98, which is why we removed the 3D stuff at that time. I assume you are already on some version of 0.98, so hopefully the transforms changes from your branch to svn HEAD will be minimal. The code diffs can be found at http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/ I also removed the TextWithDash and saw the scaling problems you point to. JDH
Hi, It took me a while to get this done, but I managed to make mplot3d working with svn trunk again! It's available for viewing at http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary. An http link to clone it is on that same page. JDH: If there are no further issues with moving this to svn, how do you want to proceed? It can surely use some more bugfixes later on and it would be great if I could commit those directly, although sending patches would be ok too. One thing I ran into: it is not possible to unset the alpha value for a Collection. Because of this it is not possible to set alpha values for individual items once a Collection-wide value is set. I think the solution would be to accept None as a value in set_alpha(); I solved it now by setting coll._alpha = None in mplot3d. (The reason this was not a problem earlier is this bug-fix: http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/colors.py?r1=6982&r2=6986) Regards, Reinier On Thu, Apr 2, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote: > Hey Reiner -- please make sure you "reply-to-all" so others can > participate in the thread. I'm am CC-ing the reply to the list. > > On Wed, Apr 1, 2009 at 5:19 PM, Reinier Heeres <re...@he...> wrote: > >> That is one issue, but if I try to solve that I get some >> strange-looking result. It seems that the patches I am drawing are not >> scaled properly; they are way too large. Do you know of any obvious >> change that might have resulted in this (I guess it might be in the >> "transform" parts)? And is there perhaps a nice web-interface to >> compare different versions of various files? > > What version of mpl are you using? The major transform work was done > between 0.91 and 0.98, which is why we removed the 3D stuff at that > time. I assume you are already on some version of 0.98, so hopefully > the transforms changes from your branch to svn HEAD will be minimal. > The code diffs can be found at > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/ > > I also removed the TextWithDash and saw the scaling problems you point to. > > JDH -- Reinier Heeres Bleijenburg 64 2511 VD Den Haag The Netherlands Tel: +31 6 10852639
On Sun, Apr 12, 2009 at 6:09 PM, Reinier Heeres <re...@he...> wrote: > Hi, > > It took me a while to get this done, but I managed to make mplot3d > working with svn trunk again! Hmm, this does not seem to be against svn HEAD on the trunk. I cloned your repo with > git clone http://qtwork.nano.tudelft.nl/public_git/users/rwh/mplot3d but am getting some errors with mpl svn HEAD. For example, johnh@flag:mplot3d> python demo.py Traceback (most recent call last): File "demo.py", line 23, in ? line, = ax.plot3d([0.2,1.8, 2.5], [0.2,.5,3.7], [0,.5,.2], 'ro') File "/home/flag/johnh/tmp/mplot3d/axes3d.py", line 528, in plot3D lines = Axes.plot(self, xs,ys, *args, **kwargs) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py", line 3357, in plot self.autoscale_view(scalex=scalex, scaley=scaley) File "/home/flag/johnh/tmp/mplot3d/axes3d.py", line 228, in autoscale_view if not self._autoscaleon: return AttributeError: 'Axes3DI' object has no attribute '_autoscaleon' And when I fix that (use self.get_autoscale_on()), I get the error I referred you to earlier in this thread about the deprecated TextWithDash johnh@flag:mplot3d> python demo.py Traceback (most recent call last): File "demo.py", line 33, in ? plt.draw() File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py", line 350, in draw get_current_fig_manager().canvas.draw() File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", line 215, in draw FigureCanvasAgg.draw(self) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", line 283, in draw self.figure.draw(self.renderer) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py", line 773, in draw for a in self.axes: a.draw(renderer) File "/home/flag/johnh/tmp/mplot3d/axes3d.py", line 181, in draw self.w_xaxis.draw(renderer) File "/home/flag/johnh/tmp/mplot3d/axis3d.py", line 410, in draw tick_update_position(tick, x,y,z, angle=angle) File "/home/flag/johnh/tmp/mplot3d/axis3d.py", line 102, in tick_update_position tick.label1.set_dashlength(8) AttributeError: 'Text' object has no attribute 'set_dashlength' Have you committed your latest? JDH
Hi, Should be working now: I did commit and push my changes, but forgot to update the http indices (that was a real head-breaker!). Instead of demo.py it is nicer to try "python axes3d.py". Hope it works! Cheers, Reinier On Mon, Apr 13, 2009 at 6:51 PM, John Hunter <jd...@gm...> wrote: > On Sun, Apr 12, 2009 at 6:09 PM, Reinier Heeres <re...@he...> wrote: >> Hi, >> >> It took me a while to get this done, but I managed to make mplot3d >> working with svn trunk again! > > Hmm, this does not seem to be against svn HEAD on the trunk. I cloned > your repo with > > > git clone http://qtwork.nano.tudelft.nl/public_git/users/rwh/mplot3d > > but am getting some errors with mpl svn HEAD. For example, > > <snip> > > Have you committed your latest? > > JDH > -- Reinier Heeres Bleijenburg 64 2511 VD Den Haag The Netherlands Tel: +31 6 10852639
On Mon, Apr 13, 2009 at 5:40 PM, Reinier Heeres <re...@he...> wrote: > Hi, > > Should be working now: I did commit and push my changes, but forgot to > update the http indices (that was a real head-breaker!). > > Instead of demo.py it is nicer to try "python axes3d.py". > > Hope it works! Worked beautifully -- *may thanks* for your continued work on this port. Many folks were disappointed to see this functionality yanked away, and it is nice to have it back. I committed it as mpl_toolkits/mplot3d and added examples/mplot3d/demo.py. This latter file actually does all of the demos that are in axes3d, so it is a bit richer than the original demo. Send me your sf id and I will add you to the committers list so you can continue to update the software. Thanks! JDH