matplotlib-devel Mailing List for matplotlib

On Thu, Sep 20, 2012 at 8:48 PM, Michael Droettboom <md...@st...> wrote:
> The source of that file has always been `matplotlibrc.template` at the root
> of the source tree. That file is copied (by the build process) to
> lib/matplotlib/mpl-data/matplotlibrc, but it doesn't exist in the raw source
> tree.
ah nice, so I was using something outdated
> I'm not sure what matplotlib.conf is or was -- but I hope
> matplotlibrc.template fits the bill for the Debian package's purposes.
Absolutely, thanks for the quick reply!
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 21 September 2012 14:38, Benjamin Root <ben...@ou...> wrote:
> On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall <
> dam...@gm...> wrote:
>
>> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...>
>> wrote:
>> > On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
>> > wrote:
>>
> 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...)
>
I am happy with option 3 too, but I don't think you need to do as much as
this. The existing 2d triplot/tripcolor/tricontour call
Triangulation.get_from_args_and_kwargs, which removes the various
args/kwargs needed for the triangulation and leaves the remainder for the
calling function to process. For example lib/matplotlib/tri/tricontour.py
lines 86 to 88:
tri, args, kwargs = \
 Triangulation.get_from_args_and_kwargs(*args, **kwargs)
z = np.asarray(args[0])
Can't you just do the same here, or am I missing something?
> 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.
>
The gain is that of more consistent naming of the mplot3d api functions.
The argument that we should keep names because they have been around for a
long time is not a strong one if the names are poor choices in the first
place. But I am not particularly concerned as I think that mplot3d has
some bigger problems to solve than this e.g. correct rendering of nested
polygons, z-order rendering, so maybe I should keep quiet about such
details!
Ian

On 09/21/2012 09:40 AM, Benjamin Root wrote:
>
>
> On Fri, Sep 21, 2012 at 9:23 AM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
>
>
> On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson <pel...@gm...
> <mailto:pel...@gm...>> wrote:
>
> @Ben: Presumably your running one of the examples. Probably
> changed with https://github.com/matplotlib/matplotlib/pull/921
>
>
>
>
> That would explain it. I forgot that the examples got modified to
> showcase other colormaps. I think the 3d plots need some more
> "pop", though. I think I will make a PR to change them from the
> "coolwarm" colormap to something a bit more appealing. The
> coolwarm colors just look dull and unappealing.
>
> Cheers!
> Ben Root
>
>
> This raises an important question, though... the matplotlib.org 
> <http://matplotlib.org> site has the older examples. That particular 
> PR was merged 4 months ago. Is the mplot3d part of the docs not 
> getting rebuilt?
The root of the documentation is still for 1.1.1 (the last released 
version). The docs that correspond to the release candidate are under 
matplotlib.org/1.2.0 (and this is linked to from the root page). Once 
the 1.2.0 release is made, this will be reversed, with 1.2.0 taking the 
top level and 1.1.1 relegated to an "archive" at matplotlib.org/1.1.1
Mike

On Fri, Sep 21, 2012 at 9:23 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson <pel...@gm...> wrote:
>
>> @Ben: Presumably your running one of the examples. Probably changed with
>> https://github.com/matplotlib/matplotlib/pull/921
>>
>>
>>
>
> That would explain it. I forgot that the examples got modified to
> showcase other colormaps. I think the 3d plots need some more "pop",
> though. I think I will make a PR to change them from the "coolwarm"
> colormap to something a bit more appealing. The coolwarm colors just look
> dull and unappealing.
>
> Cheers!
> Ben Root
>
>
This raises an important question, though... the matplotlib.org site has
the older examples. That particular PR was merged 4 months ago. Is the
mplot3d part of the docs not getting rebuilt?
Ben Root

On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall
<dam...@gm...>wrote:
> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...> wrote:
> > On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
> > 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

On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson <pel...@gm...> wrote:
> @Ben: Presumably your running one of the examples. Probably changed with
> https://github.com/matplotlib/matplotlib/pull/921
>
>
>
That would explain it. I forgot that the examples got modified to showcase
other colormaps. I think the 3d plots need some more "pop", though. I
think I will make a PR to change them from the "coolwarm" colormap to
something a bit more appealing. The coolwarm colors just look dull and
unappealing.
Cheers!
Ben Root

On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...> wrote:
> On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
> 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

@Ben: Presumably your running one of the examples. Probably changed with
https://github.com/matplotlib/matplotlib/pull/921
On 20 September 2012 18:23, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom <md...@st...>wrote:
>
>> I have tagged and created a tarball for 1.2.0rc2. The githash is
>> 656c88f3e546. The tarball is on the github download page here:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> This includes a number of important bugfixes, including things required
>> for creating Macintosh and Windows binaries. The Travis tests are also
>> now passing.
>>
>> I hope it will be easier for the binaries to be created this time. Once
>> they are available at github, I will make an announcement to
>> matplotlib-users and hopefully get some serious testing out of this thing.
>>
>> Thanks for all of the hard work!
>>
>> Mike
>>
>>
> Is it just me, or are colors looking duller?
>
> I attached before (v1.1.x) and after (v1.2.x) images.
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On 20 September 2012 22:30, Damon McDougall <dam...@gm...>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.
Forgive my cheek, but whilst you are looking at this area
mplot3d.tricontour and tricontourf need similar improvement...
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.
Thanks,
Ian