matplotlib-devel Mailing List for matplotlib (Page 2)

For the compilation problem, I am no Objective-C expert, but in C, line 
3557 should certainly read:

     NSSize pxlSize = NSMakeSize(rep->pixelsWide, rep->pixelsHigh);

I wonder if that fixes it -- but that's a total stab in the dark. This 
was a part of the code that was changed quite recently.

Mike


On 09/24/2012 01:01 PM, Russell E. Owen wrote:
> In article <505...@st...>,
>   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!
> I'm sorry that I missed the announcement until today -- I normally try
> to check news every day or two, but got too busy last week.
>
> I'm even more sorry to report that I can't build the 32-bit Mac OS X
> binary. I have appended the log. I suspect the issue is the need to use
> an old compiler for that python.
>
> The 64-bit Mac binary built just fine and I'm uploading it now. I have
> also appended the test results for it (which look fine to me).
>
> -- Russell
>
> Log of build failure on MacOS X 10.4 for python.org's 32-bit python 2.7
>
> d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$
> bdist_mpkg
> basedirlist is: ['/usr/local/', '/usr', '/usr/X11']
> ...
> gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -isysroot
> /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g
> -O3 -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
> -I/usr/local/include -I/usr/include -I/usr/X11/include
> -I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
> ckages/numpy/core/include -I/usr/local/include -I/usr/include -I.
> -I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
> ckages/numpy/core/include -Isrc -Iagg24/include -I.
> -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c
> src/_macosx.m -o build/temp.macosx-10.3-fat-2.7/src/_macosx.o
> src/_macosx.m: In function 'FigureCanvas_write_bitmap':
> src/_macosx.m:3557: error: request for member 'pixelsWide' in something
> not a structure or union
> src/_macosx.m:3557: error: request for member 'pixelsHigh' in something
> not a structure or union
> src/_macosx.m: In function 'FigureCanvas_write_bitmap':
> src/_macosx.m:3557: error: request for member 'pixelsWide' in something
> not a structure or union
> src/_macosx.m:3557: error: request for member 'pixelsHigh' in something
> not a structure or union
> lipo: can't figure out the architecture type of: /var/tmp//ccpc0juI.out
> error: command 'gcc-4.0' failed with exit status 1
> d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$
>
>
>
> Log of test results for the MacOS X 10.6 python.org 64-bit python 2.7
> build:
>
> localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
> .........................................................................
> .........................................................................
> .........SSS.K................................K..........................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> ..................................................................../Libr
> ary/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
> matplotlib/gridspec.py:298: UserWarning: This figure includes Axes that
> are not compatible with tight_layout, so its results might be incorrect.
>    warnings.warn("This figure includes Axes that are not "
> ...............................
> ----------------------------------------------------------------------
> Ran 1194 tests in 329.568s
>
> OK (KNOWNFAIL=2, SKIP=3)
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

In article <505...@st...>,
 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!

I'm sorry that I missed the announcement until today -- I normally try 
to check news every day or two, but got too busy last week.

I'm even more sorry to report that I can't build the 32-bit Mac OS X 
binary. I have appended the log. I suspect the issue is the need to use 
an old compiler for that python.

The 64-bit Mac binary built just fine and I'm uploading it now. I have 
also appended the test results for it (which look fine to me).

-- Russell

Log of build failure on MacOS X 10.4 for python.org's 32-bit python 2.7

d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$ 
bdist_mpkg
basedirlist is: ['/usr/local/', '/usr', '/usr/X11']
...
gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g 
-O3 -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 
-I/usr/local/include -I/usr/include -I/usr/X11/include 
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
ckages/numpy/core/include -I/usr/local/include -I/usr/include -I. 
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
ckages/numpy/core/include -Isrc -Iagg24/include -I. 
-I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c 
src/_macosx.m -o build/temp.macosx-10.3-fat-2.7/src/_macosx.o
src/_macosx.m: In function 'FigureCanvas_write_bitmap':
src/_macosx.m:3557: error: request for member 'pixelsWide' in something 
not a structure or union
src/_macosx.m:3557: error: request for member 'pixelsHigh' in something 
not a structure or union
src/_macosx.m: In function 'FigureCanvas_write_bitmap':
src/_macosx.m:3557: error: request for member 'pixelsWide' in something 
not a structure or union
src/_macosx.m:3557: error: request for member 'pixelsHigh' in something 
not a structure or union
lipo: can't figure out the architecture type of: /var/tmp//ccpc0juI.out
error: command 'gcc-4.0' failed with exit status 1
d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$



Log of test results for the MacOS X 10.6 python.org 64-bit python 2.7 
build:

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.........................................................................
.........................................................................
.........SSS.K................................K..........................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
..................................................................../Libr
ary/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
matplotlib/gridspec.py:298: UserWarning: This figure includes Axes that 
are not compatible with tight_layout, so its results might be incorrect.
  warnings.warn("This figure includes Axes that are not "
...............................
----------------------------------------------------------------------
Ran 1194 tests in 329.568s

OK (KNOWNFAIL=2, SKIP=3)

On Mon, Sep 24, 2012 at 2:05 PM, Michael Droettboom <md...@st...> wrote:
> Thanks for pointing this out.  It should now be fixed.
>

Nope, it still says 1.2.0rc1: http://matplotlib.org

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Mon, Sep 24, 2012 at 2:33 PM, Todd <tod...@gm...> wrote:
> This sort of plot is used ubiquitously in neuroscience.  It is used to show
> the time of discrete neural (brain cell) events (called "spikes") over time
> in repeated trials, and is generally called a spike raster, raster plot, or
> raster graph.  However, it can be used in any situation where you are only
> concerned with the position of events but not their amplitude, especially if
> you want to look for patterns in those events or look for differences
> between multiple sequences of events.

This is very closely related to "rug plots", which are often used as
an axis annotation or elsewhere where it's nice to have a small 1-d
density plot. Examples:
  https://www.cl.cam.ac.uk/~sjm217/projects/graphics/
  http://rforge.org/2009/08/10/fancy-rugs-in-regression-plots/

-n

On Mon, Sep 24, 2012 at 3:51 PM, Nathaniel Smith <nj...@po...> wrote:
> On Mon, Sep 24, 2012 at 2:33 PM, Todd <tod...@gm...> wrote:
>> This sort of plot is used ubiquitously in neuroscience.  It is used to show
>> the time of discrete neural (brain cell) events (called "spikes") over time
>> in repeated trials, and is generally called a spike raster, raster plot, or
>> raster graph.  However, it can be used in any situation where you are only
>> concerned with the position of events but not their amplitude, especially if
>> you want to look for patterns in those events or look for differences
>> between multiple sequences of events.
>
> This is very closely related to "rug plots", which are often used as
> an axis annotation or elsewhere where it's nice to have a small 1-d
> density plot. Examples:
>   https://www.cl.cam.ac.uk/~sjm217/projects/graphics/
>   http://rforge.org/2009/08/10/fancy-rugs-in-regression-plots/

The implementation I am thinking of for this plot type would also be
able to handle these sorts of plots, although it would probably
require creating horizontal and vertical variants.

I would like to add a new plot type to matplotlib.  Of course I am willing
to implement it myself, but I want to confirm that it is acceptable and
iron out the implementation details and API first so there are no major
surprises when I submit it.

I tentatively am calling the plot type an "EventRaster" plot (name
suggestions, along with any other suggestions, are welcome).  The plot is
made up if horizontal rows of identical vertical lines and/or markers.
Each line or marker represents a discrete event, and each row represents a
single sequence of events (such as a trial).  The x-axis position of the
line or marker identifies the location of the event by some measure.  An
example of what such a plot often looks like is below.

http://hebb.mit.edu/courses/9.29/2003/athena/dylanh/quad-rast.gif

This sort of plot is used ubiquitously in neuroscience.  It is used to show
the time of discrete neural (brain cell) events (called "spikes") over time
in repeated trials, and is generally called a spike raster, raster plot, or
raster graph.  However, it can be used in any situation where you are only
concerned with the position of events but not their amplitude, especially
if you want to look for patterns in those events or look for differences
between multiple sequences of events.

Plotting the timing of events is an obvious use case, such as photons
hitting photodetectors, radioactive decay events, arrival of patients to
hospitals, calls to hotlines, or car accidents in cities.  However, the
events do not have to be relative to time.  It could be position, for
example, such as tree rings along bore holes, road crossings along railroad
tracks, layers in sediment cores, or particular sequences along a DNA
strands.

I'll cover possible implementation details in the next email if everyone
thinks this is a good idea.

We welcome all volunteers!

The threshold for what requires a MEP is somewhat fuzzy, but generally 
it's for things in the core that affect the system as a whole.  Why 
don't you just start discussing your thoughts and plans here and we can 
discuss the best way forward.

Mike

On 09/24/2012 06:17 AM, Todd wrote:
> Hi, I am interested in implementing a new plot type for matplotlib.  
> Is there a specific process I should go through, or is just discussing 
> it on the mailing list sufficient?
>
> I see matplotlib has a MEP system similar to PEP, but there don't 
> appear to be that many MEPs so I don't know whether it is used in this 
> sort of situation or only for more fundamental changes.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Thanks for pointing this out.  It should now be fixed.

On 09/22/2012 01:55 PM, Damon McDougall wrote:
> On Wed, Sep 19, 2012 at 6: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
> The website says the current development version is rc1.
>

Hi, I am interested in implementing a new plot type for matplotlib.  Is
there a specific process I should go through, or is just discussing it on
the mailing list sufficient?

I see matplotlib has a MEP system similar to PEP, but there don't appear to
be that many MEPs so I don't know whether it is used in this sort of
situation or only for more fundamental changes.

On Wed, Sep 19, 2012 at 6: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

The website says the current development version is rc1.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Sat, Sep 22, 2012 at 10:40 AM, Damon McDougall
<dam...@gm...> wrote:
> Ah ok, I see. I was assuming a plot_trisurf(x, y, z, triangles, ...)
> signature. Copying the tricontour signature would be better for
> consistency reasons. It appears that I was the one missing something!

I just realised I'm not making any sense here. Please disregard most
of what I say.

I'm using the get_from_args_and_kwargs method and everything is fine.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Fri, Sep 21, 2012 at 2:38 PM, Benjamin Root <ben...@ou...> wrote:
> 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.

Technically, 1.2 hasn't been released yet. We can still change
plot_trisurf to trisurf, though it appears there is still uncertainty
regarding whether there will actually be a third release candidate.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Fri, Sep 21, 2012 at 6:21 PM, Ian Thomas <ian...@gm...> wrote:
> 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?

Ah ok, I see. I was assuming a plot_trisurf(x, y, z, triangles, ...)
signature. Copying the tricontour signature would be better for
consistency reasons. It appears that I was the one missing something!

Thanks for that.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

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

Greetings denizens,

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.

Lots of love,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On 09/20/2012 01:16 PM, Sandro Tosi wrote:
> Hi Michael,
>
> On Wed, Sep 19, 2012 at 7: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:
> Thanks for the release!
>
> I'm testing the Debian packaging, and I noticed that the file
> lib/matplotlib/mpl-data/matplotlib.conf disappeared between 1.1.1 and
> 1.2.0rc1. That was a sample file that was nice to ship to users to
> have an idea what can be customized. We were also shipping it into
> /usr/share/matplotlib/ so a first configuration was already provided
> to users. Do you have something to suggest to restore the situation? I
> don't know if you like to add the file back (maybe in a different
> location) or if we should point users to the doc and stop.
>
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.  I'm not sure what matplotlib.conf is or was -- but I hope 
matplotlibrc.template fits the bill for the Debian package's purposes.

Mike

On 20.09.2012, at 7:23PM, Benjamin Root <ben...@ou...> wrote:

> Is it just me, or are colors looking duller?
> 
> I attached before (v1.1.x) and after (v1.2.x) images.

Is this the same colour map? To me it looks like jet or rainbow vs. coolwarm. 
The latter had been endorsed by a number of people here for its visualisation 
qualities [http://www.sandia.gov/~kmorel/documents/ColorMaps/]; 
maybe it has just become the new default?

Cheers,
					Derek