On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall
<damon.mcdoug...@gmail.com>wrote:
> 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.
>
>
I agree with option 3. It fits in nicely with the paradigms of the
existing codebase (my recent contributions excluded...)
> > 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.
>
>
I wouldn't be against going down a deprecation path for renaming these
functions, but for what gains? The names have been there since before I
took up this toolkit, and ultimately, these functions aren't typed so often
that brevity would gain one much. Definitely any new functions should not
take up that naming, but I see no real compelling reason to change the
existing names.
Cheers!
Ben Root
------------------------------------------------------------------------------
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
