matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] 1.4.0rc1 has been tagged

[Eric F. <ef...@ha...>]

On 2014/07/12, 7:20 PM, Thomas Caswell wrote:
> Hey all,
>
> After a very productive sprint at scipy (according to pluse, we merged
> 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged
> the first release candidate (1.4.0rc1).
>
> There are a good number of outstanding issues with documentation (re
> the fate of pylab and installation) and one small issue with data
> cleaning in boxplots.
>
> I proposing giving our selves a 2 week deadline to have everything finalized.
>
> Tom
>

Excellent!  Thanks very much for keeping on top of all this, and for the 
amazing amount of work you have been doing.

Eric

[matplotlib-devel] 1.4.0rc1 has been tagged

[Thomas C. <tca...@gm...>]

Hey all,

After a very productive sprint at scipy (according to pluse, we merged
35 PRs in the last 3 days), I have created the 1.4.x branch and tagged
the first release candidate (1.4.0rc1).

There are a good number of outstanding issues with documentation (re
the fate of pylab and installation) and one small issue with data
cleaning in boxplots.

I proposing giving our selves a 2 week deadline to have everything finalized.

Tom

-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] Critical PR for 1.4

[Benjamin R. <ben...@ou...>]

I am currently working on a PR for mplot3d that is also release critical
because there is something broken with the API. I hope to have it sorted
out in the next hour or two.


On Sat, Jul 12, 2014 at 9:45 AM, Nelle Varoquaux <nel...@gm...>
wrote:

> Hi everyone!
> I'm currently reviewing PR critical for 1.4: can people make sure to tag
> those as release_critical? There is only two open right now.
> Cheers,
> N
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] Critical PR for 1.4

[Nelle V. <nel...@gm...>]

Hi everyone!
I'm currently reviewing PR critical for 1.4: can people make sure to tag
those as release_critical? There is only two open right now.
Cheers,
N

Re: [matplotlib-devel] Thin Axes class

[Benjamin R. <ben...@ou...>]

I wonder if the tick marks could take advantage of advantages of
Line2DCollection (if it hasn't already), or maybe go so far as to have them
be PatchCollections? We could maintain full feature set and such, but take
advantage of some of the optimized rendering pathways in the backends that
were originally made for plot()?

Just thinking off the top of my head at the moment.

Cheers!
Ben Root



On Wed, Jul 9, 2014 at 12:54 PM, Joel B. Mohler <jo...@ki...>
wrote:

> On 07/08/2014 11:33 AM, Bartosz wrote:
> > Hi,
> >
> > When improving the performance of plotting high-dimensional data using
> > faceted scatter plots, I noticed that much of time was spent on the axis
> > creation (even 50%!).
> >
> > On my machine creating 20x20 array of subplots without actually plotting
> > anything takes about 11 seconds (for comparison plotting 5000 points on
> > all of them takes only 0.6s!):
> >
> > import matplotlib
> > matplotlib.interactive(True)
> > import matplotlib.pyplot as plt
> > fig, axes = plt.subplots(20,20)
> > plt.show()
> >
> > Profiling shows that 50% of computation time is spent on axis/ticks
> > creation [1], which I have to remove anyways. Is there any easy way of
> > creating thinned axes without ticks and spines?
> >
> > So far I solved the problem by subclassing Axes class (see this gist
> > [2]) and removing all spines and ticks. Running the above example gives
> > a 10x boost in performance (from 11s to 0.9s).
> >
> > import thin_axes
> > fig, axes = plt.subplots(20,20, subplot_kw=dict(projection='thin'))
> > plt.show()
>
> Hi, I also have found tick marks to be a real performance drain and am
> trying to fix this.   I have yet to get my ideas all in a shape which is
> worthy of a pull request.  It's a rather large change under the hood and
> so there are probably quite a few edge cases which I'm not really aware
> of since I'm sure I only care about 50% (or less) of the full range of
> flexibility.  That said, simple graphs with basic tick marks are much
> slower than they need to be.
>
> My work is at https://github.com/jbmohler/mplfastaxes and I also used
> the custom projection method to replace the Axes/Axis classes. I have
> incorporated your example because I think it is interesting (even
> through 20x20 grid of axes seems crazy to me ... it may make sense
> though :) ).
>
> You have addressed a somewhat different case than myself because I've
> focused on the speed of drawing the graphics where-as your gist
> illustrates that making a new figure with many axes is very slow.  I
> believe the same ideas apply and I'm going to spend some time right now
> improving my code's initialization which is basically unchanged from MPL
> at this point.
>
> Joel
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Thin Axes class

[Joel B. M. <jo...@ki...>]

On 07/08/2014 11:33 AM, Bartosz wrote:
> Hi,
>
> When improving the performance of plotting high-dimensional data using
> faceted scatter plots, I noticed that much of time was spent on the axis
> creation (even 50%!).
>
> On my machine creating 20x20 array of subplots without actually plotting
> anything takes about 11 seconds (for comparison plotting 5000 points on
> all of them takes only 0.6s!):
>
> import matplotlib
> matplotlib.interactive(True)
> import matplotlib.pyplot as plt
> fig, axes = plt.subplots(20,20)
> plt.show()
>
> Profiling shows that 50% of computation time is spent on axis/ticks
> creation [1], which I have to remove anyways. Is there any easy way of
> creating thinned axes without ticks and spines?
>
> So far I solved the problem by subclassing Axes class (see this gist
> [2]) and removing all spines and ticks. Running the above example gives
> a 10x boost in performance (from 11s to 0.9s).
>
> import thin_axes
> fig, axes = plt.subplots(20,20, subplot_kw=dict(projection='thin'))
> plt.show()

Hi, I also have found tick marks to be a real performance drain and am 
trying to fix this.   I have yet to get my ideas all in a shape which is 
worthy of a pull request.  It's a rather large change under the hood and 
so there are probably quite a few edge cases which I'm not really aware 
of since I'm sure I only care about 50% (or less) of the full range of 
flexibility.  That said, simple graphs with basic tick marks are much 
slower than they need to be.

My work is at https://github.com/jbmohler/mplfastaxes and I also used 
the custom projection method to replace the Axes/Axis classes. I have 
incorporated your example because I think it is interesting (even 
through 20x20 grid of axes seems crazy to me ... it may make sense 
though :) ).

You have addressed a somewhat different case than myself because I've 
focused on the speed of drawing the graphics where-as your gist 
illustrates that making a new figure with many axes is very slow.  I 
believe the same ideas apply and I'm going to spend some time right now 
improving my code's initialization which is basically unchanged from MPL 
at this point.

Joel

[matplotlib-devel] Thin Axes class

[Bartosz <ma...@te...>]

Hi,

When improving the performance of plotting high-dimensional data using 
faceted scatter plots, I noticed that much of time was spent on the axis 
creation (even 50%!).

On my machine creating 20x20 array of subplots without actually plotting 
anything takes about 11 seconds (for comparison plotting 5000 points on 
all of them takes only 0.6s!):

import matplotlib
matplotlib.interactive(True)
import matplotlib.pyplot as plt
fig, axes = plt.subplots(20,20)
plt.show()

Profiling shows that 50% of computation time is spent on axis/ticks 
creation [1], which I have to remove anyways. Is there any easy way of 
creating thinned axes without ticks and spines?

So far I solved the problem by subclassing Axes class (see this gist 
[2]) and removing all spines and ticks. Running the above example gives 
a 10x boost in performance (from 11s to 0.9s).

import thin_axes
fig, axes = plt.subplots(20,20, subplot_kw=dict(projection='thin'))
plt.show()

Profiling results show more uniform distribution of computing time 
across functions (most time is spent on creating and applying transforms 
[3]).

The thinned class seems a bit hacky. Is there any other way to create a 
raw Axes object without spines, ticks, labels etc., just pure canvas 
with appropriate transforms?

Yours,

Bartosz


[1] profiling results of vanilla Axes: http://pbrd.co/1jlovoo
[2] https://gist.github.com/btel/a6b97e50e0f26a1a5eaa
[3] profiling results of thined Axes:

[matplotlib-devel] A minor bugfix for FancyBBoxPatch

[Janis K. <kal...@ce...>]

Hi there,

I might have found a bug which seems fixed by the attached patch.

The bug is in the FancyBBoxPatch class, which I encountered unsuccessfully 
trying to minimize the padding of a fancy box around a small text.

In lieu of a testcase I submit the skeleton of a command causing troubles:
        plt.annotate('{0}%'.format(100),xytext=(1,1),xy=(2,2),
                     arrowprops=dict(arrowstyle='->',
                                    connectionstyle=connstyle,
                                    color='b'
                                    ),
                    bbox=dict(facecolor='white',boxstyle='round',bounds=(1,1,1,1)),
                    color='b')

I can;t now recall the bug and I shifted away from FancyBBox and trying to 
minimize the padding. In any case, I hope it helps.

Regards,

Janis

[matplotlib-devel] 1.4.0 PR review

[Thomas C. <tca...@gm...>]

Hey,

An update on the status of getting 1.4.0 out the door.  By my count we
have 14 patches that need review and 4 issues that need patches.  It
looks like we will miss getting it tagged before scipy, but I really
hope we can at least tag and announce a rc during it.

I see that there is a MEP BoF already schedule for scipy, are sprints
formally organized or ad-hoc?

need review:

#3190 : two new style sheets.  Given that style sheets are one of the
cool new features in 1.4, I think merging these is a good idea, but
want to make sure others agree

#3188 : fixes up bugs exposed by changing behavior in numpy.  They are
changing those errors to warnings before they tag 1.9 so not urgent

#3184 : DOC added text warning to `get_window_extent` that it can take
your foot off

#3174 : fixes api break added with qt5, RELEASE CRITICAL

#3170 : a lot of changes to the FAQs, will probably need discussion at scipy

#3167 : adds error checking to `plt.subplot` and company

#3165 : restores defaults to boxplot, RELEASE CRITICAL

#3156 : DOC for adding qt5

#3121 : tweaks to rcparam for qt backends

#3112 : fixes bug in wedge.  (I really want this merged for my day job)

#2952 : turn clipping off on all objects in pie charts

#2951 : changes in  AnchoredSizeBar api.

#2843 : fixes the labels added to contour plots. It works, but could
use more internal documentation RELEASE CRITICAL

needs revision:

#2742 : add documentation about how to rebase (which is my problem,
this might get punted)

NEEDS PATCH:

#3126 : something is not right with how the the annotate docstrings
get parsed by sphinx

#3090 : proposal do stop testing 3.2 (which more-or-less drops
official support for it), easy to do but needs consensus to do it

#2999 : install docs for windows/mac, should be done by who ever
packages up the release for those platforms

#2903 : the plot directive is not always working correctly, some of
the links are screwy

Tom
-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] [Numpy-discussion] Questions about fixes for 1.9.0rc2

[Nathaniel S. <nj...@po...>]

On Fri, Jul 4, 2014 at 9:48 PM, Charles R Harris
<cha...@gm...> wrote:
>
> On Fri, Jul 4, 2014 at 2:41 PM, Nathaniel Smith <nj...@po...> wrote:
>>
>> On Fri, Jul 4, 2014 at 9:33 PM, Charles R Harris
>> <cha...@gm...> wrote:
>> >
>> > On Fri, Jul 4, 2014 at 2:09 PM, Nathaniel Smith <nj...@po...> wrote:
>> >>
>> >> On Fri, Jul 4, 2014 at 9:02 PM, Ralf Gommers <ral...@gm...>
>> >> wrote:
>> >> >
>> >> > On Fri, Jul 4, 2014 at 10:00 PM, Charles R Harris
>> >> > <cha...@gm...> wrote:
>> >> >>
>> >> >> On Fri, Jul 4, 2014 at 1:42 PM, Charles R Harris
>> >> >> <cha...@gm...> wrote:
>> >> >>>
>> >> >>> Sebastian Seberg has fixed one class of test failures due to the
>> >> >>> indexing
>> >> >>> changes in numpy 1.9.0b1.  There are some remaining errors, and in
>> >> >>> the
>> >> >>> case
>> >> >>> of the Matplotlib failures, they look to me to be Matplotlib bugs.
>> >> >>> The
>> >> >>> 2-d
>> >> >>> arrays that cause the error are returned by the overloaded
>> >> >>> _interpolate_single_key function in CubicTriInterpolator that is
>> >> >>> documented
>> >> >>> in the base class to return a 1-d array, whereas the actual
>> >> >>> dimensions
>> >> >>> are
>> >> >>> of the form (n, 1). The question is, what is the best work around
>> >> >>> here
>> >> >>> for
>> >> >>> these sorts errors? Can we afford to break Matplotlib and other
>> >> >>> packages on
>> >> >>> account of a bug that was previously accepted by Numpy?
>> >> >
>> >> >
>> >> > It depends how bad the break is, but in principle I'd say that
>> >> > breaking
>> >> > Matplotlib is not OK.
>> >>
>> >> I agree. If it's easy to hack around it and issue a warning for now,
>> >> and doesn't have other negative consequences, then IMO we should give
>> >> matplotlib a release or so worth of grace period to fix things.
>> >
>> >
>> > Here is another example, from skimage.
>> >
>> > ======================================================================
>> > ERROR: test_join.test_relabel_sequential_offset1
>> > ----------------------------------------------------------------------
>> > Traceback (most recent call last):
>> >   File "X:\Python27-x64\lib\site-packages\nose\case.py", line 197, in
>> > runTest
>> >     self.test(*self.arg)
>> >   File
>> >
>> > "X:\Python27-x64\lib\site-packages\skimage\segmentation\tests\test_join.py",
>> > line 30, in test_relabel_sequential_offset1
>> >     ar_relab, fw, inv = relabel_sequential(ar)
>> >   File
>> > "X:\Python27-x64\lib\site-packages\skimage\segmentation\_join.py",
>> > line 127, in relabel_sequential
>> >     forward_map[labels0] = np.arange(offset, offset + len(labels0) + 1)
>> > ValueError: shape mismatch: value array of shape (6,) could not be
>> > broadcast
>> > to indexing result of shape (5,)
>> >
>> > Which is pretty clearly a coding error. Unfortunately, the error is in
>> > the
>> > package rather than the test.
>> >
>> > The only easy way to fix all of these sorts of things is to revert the
>> > indexing changes, and I'm loathe to do that. Grrr...
>>
>> Ugh, that's pretty bad :-/. Do you really think we can't use a
>> band-aid over the new indexing code, though?
>
>
> Yeah, we can. But Sebastian doesn't have time and I'm unfamiliar with the
> code, so it may take a while...

Fair enough!

I guess that if what are (arguably) bugs in matplotlib and
scikit-image are holding up the numpy release, then it's worth CC'ing
their mailing lists in case someone feels like volunteering to fix
it... ;-).

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

Re: [matplotlib-devel] tick marks and render speed

[Joel B. M. <jo...@ki...>]

On Thu, Jun 26, 2014 at 02:36:28PM -0400, Benjamin Root wrote:
> This is very interesting. I have also noticed that ticking has been a
> bottleneck in rendering, but always suspected the computation of the ticks
> rather than the actual rendering of the marks. Perhaps this might spur some
> renewed interest in identifying the specific reason for the bottleneck and
> solving that issue now that we know that there are significant performance
> gain potential here?

I'm thinking about "specific reasons":

1)  Path.__init__ does mysterious stuff (at least, mysterious to me) and seems
designed to handle many different inputs in various stages of readiness for
something.  It is also called many times in the course of getting a graph on
screen and it isn't very fast.  I think the checking and rechecking vertices is
needlessly expensive in particular around TransformedPath.  This is deep stuff
and I'm too novice.

1a)  Line2D.recache is a big hunk in the profiler, but that's partly due to #1.

2)  The loops in axis.py over major_ticks and minor_ticks are repeated in time
sensitive areas and apply the same things to many sub-objects.  This is the
issue that my current ideas are addressing.

3)  If one addresses 1&2, the next largest elephant appears to be text
rendering.

While fixing #1 is a really good idea, it's hard work and the multitude of
explicit tick objects of #2 will always have a great deal of python call
overhead.

Fixing #3 has little low-hanging fruit.  I've seen
https://github.com/matplotlib/matplotlib/issues/347 and a 20% gain would be
a noticeable improvement on the graphs I'm working on (but only after #2 is
addressed).  Of course, I'm not sure of what total quantity mdboom's 20%
referred to.

Joel

PS:  all of these thoughts are brought to you by snakeviz ... nice profile
visualizer

> 
> Looking forward to reviewing this at some point in the next few weeks.
> 
> Cheers!
> Ben Root
> 
> 
> 
> On Thu, Jun 26, 2014 at 2:10 PM, Joel B. Mohler <jo...@ki...>
> wrote:
> 
> > About a week ago I sent a message to the users mailing list with tick mark
> > performance problems.  I now have a proof of concept patch which
> > (mis-)uses the
> > projection keyword in add_subplot to use a custom Axes class.  Import one
> > python file, use "projection='fastticks'" -> boring scatter plots render
> > about
> > 2x as fast and plots with lots of minor ticks render 6x faster.
> >
> > The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is
> > in
> > fastaxes.py which uses a single Line2D for all tick marks of a given flavor
> > rather than a Line2D for every single tick mark.
> >
> > There are two reasons this isn't a total win:
> > 1)  it's not done yet in all tick/grid configurations.
> > 2)  it loses flexibility in tick labeling
> >
> > The lost flexibility may matter a great deal to other people.  In my
> > use-case,
> > the labeling flexibility simply seems misguided and the performance is much
> > much preferred.
> >
> > Comments welcome about how this could move forward toward being included in
> > MPL.
> >
> > Joel
> >
> >
> > ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >

Re: [matplotlib-devel] nosetests: too slow, too much memory

[Benjamin R. <ben...@ou...>]

False alarm. The Travis logs includes (but hides) the install output, and
test_mlab was running for me, but I was looking at the wrong line
numbers.   Still though, I would be curious as to any differences, but I
can't seem to download the log file.

Ben


On Thu, Jun 26, 2014 at 6:57 PM, Benjamin Root <ben...@ou...> wrote:

> Just noticed an oddity with the tests on Travis versus the tests on my
> machine. The test log on Travis for a single run has over 10,000 lines.
> But, for me, it is over ~4800 lines. At a glance, I can see that test_mlab
> is not executed for me, but they are for Travis. I am very suspicious of
> the test_mlab run on Travis because it seems to be running multiple times,
> but I can't be sure.
>
> Michael, can I get the test log for one of the recent Travis runs?
>
> Thanks,
> Ben Root
>
>
>
> On Wed, Jun 4, 2014 at 1:49 PM, Benjamin Root <ben...@ou...> wrote:
>
>> So, I just tried comparing memory usage for a plot displayed via show()
>> versus savefig() as a PNG. It would seem that saving to pngs uses more
>> memory. Not sure why, though.
>>
>> Ben
>> On Jun 4, 2014 12:57 PM, "Eric Firing" <ef...@ha...> wrote:
>>
>>> On 2014/06/04 6:26 AM, Benjamin Root wrote:
>>>
>>>> A theory...
>>>>
>>>> If I remember correctly, the nosttests was set up to execute in parallel
>>>> using the default Multiprocessing settings, which is to have a process
>>>> worker for each available CPU core. Perhaps this might be the crux of
>>>> the issue with so many simultaneous tests running that the amount of
>>>> memory used at the same time becomes too large. Or, am I thinking of the
>>>> doc build system?
>>>>
>>>> Ben Root
>>>>
>>>
>>> Ben,
>>>
>>> Top shows a single process.  The VM is configured with 2 cores.
>>>
>>> Eric
>>>
>>
>

Re: [matplotlib-devel] nosetests: too slow, too much memory

[Benjamin R. <ben...@ou...>]

Just noticed an oddity with the tests on Travis versus the tests on my
machine. The test log on Travis for a single run has over 10,000 lines.
But, for me, it is over ~4800 lines. At a glance, I can see that test_mlab
is not executed for me, but they are for Travis. I am very suspicious of
the test_mlab run on Travis because it seems to be running multiple times,
but I can't be sure.

Michael, can I get the test log for one of the recent Travis runs?

Thanks,
Ben Root



On Wed, Jun 4, 2014 at 1:49 PM, Benjamin Root <ben...@ou...> wrote:

> So, I just tried comparing memory usage for a plot displayed via show()
> versus savefig() as a PNG. It would seem that saving to pngs uses more
> memory. Not sure why, though.
>
> Ben
> On Jun 4, 2014 12:57 PM, "Eric Firing" <ef...@ha...> wrote:
>
>> On 2014/06/04 6:26 AM, Benjamin Root wrote:
>>
>>> A theory...
>>>
>>> If I remember correctly, the nosttests was set up to execute in parallel
>>> using the default Multiprocessing settings, which is to have a process
>>> worker for each available CPU core. Perhaps this might be the crux of
>>> the issue with so many simultaneous tests running that the amount of
>>> memory used at the same time becomes too large. Or, am I thinking of the
>>> doc build system?
>>>
>>> Ben Root
>>>
>>
>> Ben,
>>
>> Top shows a single process.  The VM is configured with 2 cores.
>>
>> Eric
>>
>

Re: [matplotlib-devel] tick marks and render speed

[Benjamin R. <ben...@ou...>]

This is very interesting. I have also noticed that ticking has been a
bottleneck in rendering, but always suspected the computation of the ticks
rather than the actual rendering of the marks. Perhaps this might spur some
renewed interest in identifying the specific reason for the bottleneck and
solving that issue now that we know that there are significant performance
gain potential here?

Looking forward to reviewing this at some point in the next few weeks.

Cheers!
Ben Root



On Thu, Jun 26, 2014 at 2:10 PM, Joel B. Mohler <jo...@ki...>
wrote:

> About a week ago I sent a message to the users mailing list with tick mark
> performance problems.  I now have a proof of concept patch which
> (mis-)uses the
> projection keyword in add_subplot to use a custom Axes class.  Import one
> python file, use "projection='fastticks'" -> boring scatter plots render
> about
> 2x as fast and plots with lots of minor ticks render 6x faster.
>
> The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is
> in
> fastaxes.py which uses a single Line2D for all tick marks of a given flavor
> rather than a Line2D for every single tick mark.
>
> There are two reasons this isn't a total win:
> 1)  it's not done yet in all tick/grid configurations.
> 2)  it loses flexibility in tick labeling
>
> The lost flexibility may matter a great deal to other people.  In my
> use-case,
> the labeling flexibility simply seems misguided and the performance is much
> much preferred.
>
> Comments welcome about how this could move forward toward being included in
> MPL.
>
> Joel
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] tick marks and render speed

[Joel B. M. <jo...@ki...>]

About a week ago I sent a message to the users mailing list with tick mark
performance problems.  I now have a proof of concept patch which (mis-)uses the
projection keyword in add_subplot to use a custom Axes class.  Import one
python file, use "projection='fastticks'" -> boring scatter plots render about
2x as fast and plots with lots of minor ticks render 6x faster.

The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is in
fastaxes.py which uses a single Line2D for all tick marks of a given flavor
rather than a Line2D for every single tick mark.

There are two reasons this isn't a total win:
1)  it's not done yet in all tick/grid configurations.
2)  it loses flexibility in tick labeling

The lost flexibility may matter a great deal to other people.  In my use-case,
the labeling flexibility simply seems misguided and the performance is much
much preferred.

Comments welcome about how this could move forward toward being included in
MPL.

Joel

Re: [matplotlib-devel] subtle change in trisurf image results

[Ian T. <ian...@gm...>]

On 25 June 2014 17:55, Benjamin Root <ben...@ou...> wrote:

> The mplot3d tests are not run automatically, so I have no idea when this
> change happened. But I would suspect it is related to the changes in
> triangulation rather than with mplot3d itself. I have zero expertise to say
> if one result is more correct than the other. See attached.
>
> I should note that this particular difference was within the default
> tolerance. It was the rendering to PDF that seemed to have enough
> difference to trigger a failure.
>

Ben,

You are right, this change occurred when the underlying triangulation code
was switched to using qhull.  Both before and after pictures are equally
correct.

A rectangle in the x-y plane is split into two triangles by adding a
diagonal.  The shortest of the two diagonals should added, so for the
analytical solution either diagonal is equally valid.  In practice the
choice of diagonal depends on the order of operations in the underlying
algorithm and how these interact with finite machine precision.

Rather than just changing the test image, a better solution would be to
modify the relevant example/test code to avoid such degenerate cases that
can give problems in the future.  The source code for trisurf3d_demo (
http://matplotlib.org/examples/mplot3d/trisurf3d_demo.html) is clearly
derived from tripcolor_demo (
http://matplotlib.org/examples/pylab_examples/tripcolor_demo.html), but
omits the key line near the beginning of

angles[:,1::2] += math.pi/n_angles

Putting this line back in will avoid similar problems in the future, and
improve the images too.

Ian

Re: [matplotlib-devel] tests.py missing

[Matthew B. <mat...@gm...>]

Hi,

On Wed, Jun 25, 2014 at 4:49 PM,  <kei...@bt...> wrote:
> Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.
>
> kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py
>
> Keith
>
> ________________________________________
> From: ben...@gm... [ben...@gm...] On Behalf Of Benjamin Root [ben...@ou...]
> Sent: 25 June 2014 16:45
> To: Briggs,KM,Keith,TUB2 R
> Cc: matplotlib development list
> Subject: Re: [matplotlib-devel] tests.py missing
>
> It is right there in the root directory for the distribution:
>
> https://github.com/matplotlib/matplotlib/tree/v1.3.x
>
>
> On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...<mailto:kei...@bt...>> wrote:
> README.rst in matplotlib-1.3.1 says:
>
>> After installation, you can launch the test suite::
>>
>> python tests.py
>
> but actually there is no tests.py anywhere in the distribution.

Actually, it would be very good to have the tests.py file somewhere
from a standard install - I had to hack round that for automated tests
of a pip tarball, for example, by downloading the test.py separately.

Cheers,

Matthew

Re: [matplotlib-devel] tests.py missing

[Benjamin R. <ben...@ou...>]

Heh... well, that's a horse of a different color! We will have to make sure
it is in there for the upcoming release.

Cheers!
Ben Root


On Wed, Jun 25, 2014 at 11:49 AM, <kei...@bt...> wrote:

> Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.
>
> kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py
>
> Keith
>
> ________________________________________
> From: ben...@gm... [ben...@gm...] On Behalf Of Benjamin
> Root [ben...@ou...]
> Sent: 25 June 2014 16:45
> To: Briggs,KM,Keith,TUB2 R
> Cc: matplotlib development list
> Subject: Re: [matplotlib-devel] tests.py missing
>
> It is right there in the root directory for the distribution:
>
> https://github.com/matplotlib/matplotlib/tree/v1.3.x
>
>
> On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...<mailto:
> kei...@bt...>> wrote:
> README.rst in matplotlib-1.3.1 says:
>
> > After installation, you can launch the test suite::
> >
> > python tests.py
>
> but actually there is no tests.py anywhere in the distribution.
>
> Keith
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...<mailto:
> Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] tests.py missing

[<kei...@bt...>]

Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.

kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py

Keith

________________________________________
From: ben...@gm... [ben...@gm...] On Behalf Of Benjamin Root [ben...@ou...]
Sent: 25 June 2014 16:45
To: Briggs,KM,Keith,TUB2 R
Cc: matplotlib development list
Subject: Re: [matplotlib-devel] tests.py missing

It is right there in the root directory for the distribution:

https://github.com/matplotlib/matplotlib/tree/v1.3.x


On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...<mailto:kei...@bt...>> wrote:
README.rst in matplotlib-1.3.1 says:

> After installation, you can launch the test suite::
>
> python tests.py

but actually there is no tests.py anywhere in the distribution.

Keith
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] tests.py missing

[Benjamin R. <ben...@ou...>]

It is right there in the root directory for the distribution:

https://github.com/matplotlib/matplotlib/tree/v1.3.x


On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...> wrote:

> README.rst in matplotlib-1.3.1 says:
>
> > After installation, you can launch the test suite::
> >
> > python tests.py
>
> but actually there is no tests.py anywhere in the distribution.
>
> Keith
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Matthew B. <mat...@gm...>]

On Fri, Jun 20, 2014 at 12:01 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker <chr...@no...> wrote:
>> On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen <ro...@uw...> wrote:
>>>
>>> What I need is a python, numpy, and matplotlib that support 32-bit and
>>> (preferably) 64-bit for MacOS X 10.6 and later. I have been using
>>> python.org python and the standard binary installers until now.
>>
>>
>> well we (that is, Matthew) have scripts that build those, so no reason not
>> to keep doing it.
>>
>>>
>>> Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is
>>> required for older versions of Tcl/Tk to run under Mavericks
>>
>>
>> kind of ironic that the latest OS doesn't end up supporting 64 bit!
>>
>>>
>>> I realize I'm in an unusual situation,
>>
>>
>> maybe -- but tkInter is part of the standard library, so we probably do want
>> to support it! If nothing else, various folks that teach Python use the
>> turtle module early on -- and one of the use cases for
>> easy-to-fine-and-install binaries is newbies...
>
> Updating for those of you not on the numpy mailing list - I've
> uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be
> good for 32-bit compatibility now.  I hope that will continue for at
> least a couple of years, because I've automated the 32 / 64 bit build
> process [1] and added 32-bit tests to my scipy-stack test rig [2].
>
> So, I think it is time to rename the matplotlib wheels as I proposed
> at the beginning of the thread.  I propose to do that tomorrow unless
> anyone can think of a reason not to.

Done - please let me know if you have any problems.

Matthew

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Matthew B. <mat...@gm...>]

Hi,

On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker <chr...@no...> wrote:
> On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen <ro...@uw...> wrote:
>>
>> What I need is a python, numpy, and matplotlib that support 32-bit and
>> (preferably) 64-bit for MacOS X 10.6 and later. I have been using
>> python.org python and the standard binary installers until now.
>
>
> well we (that is, Matthew) have scripts that build those, so no reason not
> to keep doing it.
>
>>
>> Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is
>> required for older versions of Tcl/Tk to run under Mavericks
>
>
> kind of ironic that the latest OS doesn't end up supporting 64 bit!
>
>>
>> I realize I'm in an unusual situation,
>
>
> maybe -- but tkInter is part of the standard library, so we probably do want
> to support it! If nothing else, various folks that teach Python use the
> turtle module early on -- and one of the use cases for
> easy-to-fine-and-install binaries is newbies...

Updating for those of you not on the numpy mailing list - I've
uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be
good for 32-bit compatibility now.  I hope that will continue for at
least a couple of years, because I've automated the 32 / 64 bit build
process [1] and added 32-bit tests to my scipy-stack test rig [2].

So, I think it is time to rename the matplotlib wheels as I proposed
at the beginning of the thread.  I propose to do that tomorrow unless
anyone can think of a reason not to.

Cheers,

Matthew

[1] https://github.com/matthew-brett/numpy-atlas-binaries
[2] https://travis-ci.org/matthew-brett/scipy-stack-osx-testing

[matplotlib-devel] tests.py missing

[<kei...@bt...>]

README.rst in matplotlib-1.3.1 says:

> After installation, you can launch the test suite::
> 
> python tests.py

but actually there is no tests.py anywhere in the distribution.

Keith

Re: [matplotlib-devel] strange message in contour

[Benjamin R. <ben...@ou...>]

Which version of matplotlib are you using? Also, do you have an example
dataset and a simple, self-contained example to demonstrate this?

Chances are, there are NaNs occurring in the calculation, but since we have
code elsewhere that handles NaNs properly, it probably isn't impacting your
graph. However, it *might* be a sign that there is something
wrong/unexpected with your input data (or maybe even the contour levels
themselves).

Cheers!
Ben Root



On Tue, Jun 17, 2014 at 6:45 AM, <kei...@bt...> wrote:

> Using pyplot.contour, I'm getting
>
> /usr/lib/pymodules/python2.7/matplotlib/contour.py:374: RuntimeWarning:
> invalid value encountered in true_divide
>   dist = np.add.reduce(([(abs(s)[i]/L[i]) for i in range(xsize)]),-1)
>
> although the resulting plot seems to be ok.
>
> Keith
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] strange message in contour

[<kei...@bt...>]

Using pyplot.contour, I'm getting

/usr/lib/pymodules/python2.7/matplotlib/contour.py:374: RuntimeWarning: invalid value encountered in true_divide
  dist = np.add.reduce(([(abs(s)[i]/L[i]) for i in range(xsize)]),-1)

although the resulting plot seems to be ok.

Keith