matplotlib-devel Mailing List for matplotlib

I am experimenting with my idea for utilizing a _draworder attribute in
Collection objects. Since not everything in a collection is guaranteed to
be the same length or even be numpy arrays, I have to add some logic to
coerce everything to numpy arrays and tile their data so that the length of
their first axis match up.
I also have logic to convert all objects back to their original types prior
to continuing, just in case that makes any difference.
However, using AGG seems to fail here:
Traceback (most recent call last):
 File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line
197, in runTest
 self.test(*self.arg)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 51, in failer
 result = f(*args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 183, in do_test
 figure.savefig(actual_fname, **self._savefig_kwarg)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
line 1490, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backend_bases.py",
line 2211, in print_figure
 **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
line 525, in print_png
 FigureCanvasAgg.draw(self)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
line 472, in draw
 self.figure.draw(self.renderer)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
line 60, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
line 1094, in draw
 func(*args)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axes3d.py",
line 273, in draw
 ax.draw(renderer)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axis3d.py",
line 370, in draw
 self.gridlines.draw(renderer, project=True)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/art3d.py",
line 203, in draw
 LineCollection.draw(self, renderer)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
line 60, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/collections.py",
line 345, in draw
 self._offset_position)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
line 127, in draw_path_collection
 return self._renderer.draw_path_collection(*kl, **kw)
SystemError: new style getargs format but argument is not a tuple
The PDF and SVG backends aren't experiencing this problem. I have taken out
the parts of my code that "broadcasted" the arrays, and the error still
happens. I then took out the code that coerced everything to numpy arrays
in the first place, and the error disappeared (taking that out effectively
let everything pass through unaffected). Keep in mind that my code coerced
everything back to their original types prior to calling the renderer, so
it was merely the action of converting stuff into an array that did this.
The best I can figure is that there is something wrong with the C++ code
for our agg wrapper? Googling the exception message brings up various
discussions of mistakes in the argument handling of C/C++ code. I haven't a
clue, though, why this would be an issue.
Thoughts?
Ben Root

On 2015年02月08日 12:05 PM, Thomas Caswell wrote:
> The goal of pulling pyplot out of backend_bases is exactly that, to be
> able to do everything using the OO interface in a convenient way.
>
https://github.com/matplotlib/matplotlib/pull/4082
The above PR is an illustration of one approach to making the OO 
interface draw like the pyplot interface does in interactive mode. 
There may be a better way to do it, but this way is quite simple and 
non-intrusive.
Eric

To overhauling all of the default colors, I think that is still in the
cards, but some one who is not me needs to drive that.
The goal of pulling pyplot out of backend_bases is exactly that, to be able
to do everything using the OO interface in a convenient way.
Tom
On Sun Feb 08 2015 at 4:50:51 PM Todd <tod...@gm...> wrote:
>
> On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> wrote:
> >
> > Hey all,
> >
> > To start with, the 2.0 release is pending a choice of new default color
> map. I think that when we pick that we should cut 2.0 off of the last
> release and then the next minor release turns into 2.1. If we want to do
> other breaking changes we will just do a 3.0 when that happens. It makes
> sense to me to bundle default color changes as one set of breaking changes
> and code API changes as another.
>
> I thought there was going to be a complete overhaul of the default theme?
> Has that idea been abandoned?
>
> > - making OO interface easier to use interactively (if interactive,
> auto-redraw at sensible time)
> >
> > - pull the pyplot state machine out of backend_bases and expose the
> figure_manager classes
>
> Do either of these mean that it will be possible to use the OO interface
> without needing to go through pyplot?
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> wrote:
>
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color
map. I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1. If we want to do
other breaking changes we will just do a 3.0 when that happens. It makes
sense to me to bundle default color changes as one set of breaking changes
and code API changes as another.
I thought there was going to be a complete overhaul of the default theme?
Has that idea been abandoned?
> - making OO interface easier to use interactively (if interactive,
auto-redraw at sensible time)
>
> - pull the pyplot state machine out of backend_bases and expose the
figure_manager classes
Do either of these mean that it will be possible to use the OO interface
without needing to go through pyplot?

Ah, no I mean the exact opposite!
My proposal is to cut 2.0 off of what ever the current stable release is
(ex, 1.4.3) and then merge that into master. The next minor release would
then be 2.1 and there would be no new 1.Y releases.
Tom
On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi <mo...@de...> wrote:
> Hi all!
>
> On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...>
> wrote:
> > Hey all,
> >
> > To start with, the 2.0 release is pending a choice of new default color
> map.
> > I think that when we pick that we should cut 2.0 off of the last release
> and
> > then the next minor release turns into 2.1. If we want to do other
> breaking
> > changes we will just do a 3.0 when that happens. It makes sense to me to
> > bundle default color changes as one set of breaking changes and code API
> > changes as another.
> >
> > Eric made the case in an issue that we should not continue the 1.4.x
> series
> > and start working 1.5.0, which fits well with aiming for a 6month
> scheduled
> > release cycle (minor release in July, bug-fix release in February).
>
> Do I understand correctly you plan to maintain 2 separate development
> lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

Hi all!
On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...> wrote:
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color map.
> I think that when we pick that we should cut 2.0 off of the last release and
> then the next minor release turns into 2.1. If we want to do other breaking
> changes we will just do a 3.0 when that happens. It makes sense to me to
> bundle default color changes as one set of breaking changes and code API
> changes as another.
>
> Eric made the case in an issue that we should not continue the 1.4.x series
> and start working 1.5.0, which fits well with aiming for a 6month scheduled
> release cycle (minor release in July, bug-fix release in February).
Do I understand correctly you plan to maintain 2 separate development
lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell <tca...@gm...> wrote:
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
>
> If you want to tracking GH for debian instead of SF I don't think that would
> be a bad idea, but I don't know how much of a hassle that would be for you.
Aaah dont worry about changing things :) I can reroute the tools to
track GH no problem, what I need to know if that's the place where the
next tarballs will be released; if so, I will update the tracking
straight away.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I am getting some test failures here and on master in the collections
module.
======================================================================
FAIL: __main__.test_regularpolycollection_rotate.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line
197, in runTest
 self.test(*self.arg)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 51, in failer
 result = f(*args, **kwargs)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 196, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png
vs.
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png
(RMS 54.618)
======================================================================
FAIL: __main__.test_regularpolycollection_scale.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line
197, in runTest
 self.test(*self.arg)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 51, in failer
 result = f(*args, **kwargs)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 196, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png
vs.
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png
(RMS 120.828)
----------------------------------------------------------------------
Ran 54 tests in 15.149s
FAILED (failures=2)
The squares in the first test are larger than they should be. I have some
other errors, but they seem to other be floating point errors, or issues
with fonts.
Ben Root
On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell <tca...@gm...> wrote:
> Sandro,
>
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
>
> If you want to tracking GH for debian instead of SF I don't think that
> would be a bad idea, but I don't know how much of a hassle that would be
> for you.
>
> Tom
>
> On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
>
>> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...>
>> wrote:
>> > Sandro,
>> >
>> > Can you use the tarball from github
>> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>>
>> Sure I can, but since all the previous release (even RC) were done one
>> SF, we have our tools to monitor and download new releases pointing to
>> SF: do you plan to switch to GH for releasing tarballs too?
>>
>> Cheers,
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Looking at collections.py, it looks like TriMesh might also benefit from
this, as it has specialized code for masking out triangles and determining
the order of the triangle elements.
Ben Root
On Sat, Feb 7, 2015 at 7:18 PM, Benjamin Root <ben...@ou...> wrote:
> Digging through mplot3d (again), I have come to realize that a lot of its
> code in art3d.py could be simplified if we had a way to tell collection
> objects in what order to draw their elements.
>
> My proposal is fairly straight-forward. All collections would have an
> internal _zdraworder attribute that can be anything that can index a numpy
> array: slice(), array of indices, whatever. The draw() methods will then
> iterate over their elements returned by indexing with _zdraworder. This
> will help keep the bookkeeping to a minimum, because everything should be
> sliced/indexed the same way: offsets, verts, facecolors, etc.
>
> The default value will be slice(None), so nothing will change for regular
> collections.
>
> With this, mplot3d can greatly simplify its logic and semantics by
> focusing on projecting and setting the _zdraworder by running np.argsort()
> on the projected depth of the elements. Another advantage is that methods
> like get_facecolors() and set_facecolors() can round-trip in mplot3d (right
> now, get_facecolors() has to return a z-sorted version of the colors for
> drawing).
>
> For now, I imagine keeping this a private attribute, but I could see some
> really fancy tricks in the future such as using boolean indexing to mark
> some elements as visible/invisible, and doing some neat tricks for
> animations.
>
> Thoughts?
> Ben Root
>

Digging through mplot3d (again), I have come to realize that a lot of its
code in art3d.py could be simplified if we had a way to tell collection
objects in what order to draw their elements.
My proposal is fairly straight-forward. All collections would have an
internal _zdraworder attribute that can be anything that can index a numpy
array: slice(), array of indices, whatever. The draw() methods will then
iterate over their elements returned by indexing with _zdraworder. This
will help keep the bookkeeping to a minimum, because everything should be
sliced/indexed the same way: offsets, verts, facecolors, etc.
The default value will be slice(None), so nothing will change for regular
collections.
With this, mplot3d can greatly simplify its logic and semantics by focusing
on projecting and setting the _zdraworder by running np.argsort() on the
projected depth of the elements. Another advantage is that methods like
get_facecolors() and set_facecolors() can round-trip in mplot3d (right now,
get_facecolors() has to return a z-sorted version of the colors for
drawing).
For now, I imagine keeping this a private attribute, but I could see some
really fancy tricks in the future such as using boolean indexing to mark
some elements as visible/invisible, and doing some neat tricks for
animations.
Thoughts?
Ben Root

Hey all,
To start with, the 2.0 release is pending a choice of new default color
map. I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1. If we want to do
other breaking changes we will just do a 3.0 when that happens. It makes
sense to me to bundle default color changes as one set of breaking changes
and code API changes as another.
Eric made the case in an issue that we should not continue the 1.4.x series
and start working 1.5.0, which fits well with aiming for a 6month scheduled
release cycle (minor release in July, bug-fix release in February).
To this end, I have clean out and close the 1.4.x milestone (most of issues
just got moved 1.5.0) and created a 1.5.0 milestone. I set a target for
1.5.0 to be released at scipy as that seems like a reasonable thing to.
Targeting just after SciPy also makes sense so we have a clear list of
things to work on at the sprints. Thoughts?
My internal list of what we should try to get in for 1.5.0 are:
 - visitor pattern on all artists + recreating figure from it's visited
artists. This gets us a) proper serialization of our figures instead of
going through pickles and b) makes interoperability with plotly/b3/bokeh
easier
 - pyplot overhaul (use decorators, provide decorators as part of public
API)
 - navigation by events (PR #3652 + MEP22)
 - making OO interface easier to use interactively (if interactive,
auto-redraw at sensible time)
 - pull the pyplot state machine out of backend_bases and expose the
figure_manager classes
 - overhaul the website
Anything else people think should be on the list or any protests to this
list?
Tom