On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ianthoma...@gmail.com> wrote: > On 20 September 2012 22:30, Damon McDougall <damon.mcdoug...@gmail.com> > wrote: >> >> I have been playing with custom triangulations in the plot_trisurf >> method of the mplot3d toolkit. I thought I would share my sweet >> creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png >> >> Let me know your thoughts. I should probably make a pull request out >> of this, but the code is not currently readable by humans. I will tidy >> it up first. Make it look purrty. > > > Yes please! Ideally it would be good if all mplot3d functions supported the > same arg and kwarg combinations as their 2d equivalents, for consistency. > You may have done this already, but if not you might find the 2d tripcolor > code helpful - it calls Triangulation.get_from_args_and_kwargs(*args, > **kwargs) to do the initial heavy lifting. >
Yes, I had seen it. Thank you. Unfortunately, using this is non-trivial when you have an extra 'z' variable. There are a couple of options to get around this: 1. Re-write a 3d version and add it to matplotlib.tri. Pros of this approach are that the 3d methods would basically only require one extra line, a call to Triangulation.get_from_args_and_kwargs_3d(*args, **kwargs). Cons of this approach are code repetition. Also, I'm not a fan of putting 3d code into main mpl codebase. I think it should stay in the toolkit. 2. Implement option 1. but in the mplot3d toolkit rather than the main codebase. 3. Create a new args_2d tuple exactly equal to *args but with 'z' removed. Then rely on the 2d code with: Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this option would be common to all 3d functions relying on the 2d heavy lifting, it could be wrapped up into a convenience function. In my opinion, option 3. is preferable. Option 3. will also produce commits with the highest signal-to-noise ratio. > Forgive my cheek, but whilst you are looking at this area mplot3d.tricontour > and tricontourf need similar improvement... > Forgiven. I might as well do it whilst I'm already half-way down the rabbit hole. > A wider issue, and something I should have mentioned when you first > implemented plot_trisurf, is that I don't like the function name. It seems > unnecessary to have the plot_ at the front as most of the other plot-related > functions manage without it. My unease extends to plot_surface and > plot_wireframe as well. I guess we can't just change such names now that > they are being used, but eventually I would like to see better naming within > mplot3d. > Agreed. Not sure how best to solve this. Furthermore, I think it should be implemented in a pull request separate to the one migrating these 3d methods to custom triangulations. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
