Re: [matplotlib-devel] git migration this weekend

[Darren Dale]

On Wed, Feb 16, 2011 at 7:57 PM, Michael Droettboom  wrote:
> On 02/16/2011 03:53 PM, John Hunter wrote:
>> On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom  wrote:
>>> Not sure Sourceforge allows custom hooks in SVN.
>> We have a couple in place already
>>
>>
>> https://sourceforge.net/project/admin/svn.php?group_id=80706
> Yes.  But those aren't custom -- SF only provides a fixed set of scripts
> one can apply.  Notably, I don't think there's one that prevents further
> commits.

If that is the case, then let's just change the permissions for all
the devs to read-only. We can leave the tracker, feature requests, and
so forth enabled until we are ready to disable them at some later
time. Once the website is online at matplotlib.github.com, we can
follow the directions for "project relocation" at
https://sourceforge.net/project/admin/removal.php?group_id=80706 .
SourceForge will keep the project intact as an archive.

Darren

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Empty scatter plot

[Benjamin Root]

On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root  wrote:

> On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root  wrote:
>
>> On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root  wrote:
>>
>>>
>>>
>>> On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing  wrote:
>>>
 On 02/15/2011 08:50 AM, Benjamin Root wrote:

> On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root  > wrote:
>
>On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing > wrote:
>
>On 02/15/2011 07:40 AM, Benjamin Root wrote:
> > I have come across a little inconsistency that was unexpected
>in the
> > matplotlib API.  The following is perfectly valid:
> >
> > import matplotlib.pyplot as plt
> > plt.plot([], [])
> > plt.show()
> >
> >
> > However, this is not valid:
> >
> > import matplotlib.pyplot as plt
> > plt.scatter([], [])
> > plt.show()
> >
> >
> > The immediate issue that comes up in scatter is that it
>attempts to find
> > min/max of the input data for the purpose of autoscaling
>(this can
> > probably be done better by just using set_xmargin(0.05) and
> > set_ymargin(0.05)).  This can easily be bypassed with an if
>statement.
> > However, then we discover that polygon collection do not like
>having
> > empty offsets, which leads to a failure in the affine
>transformation.
> >
> > So, the question is, is this a bug or a feature?  I
>personally believe
> > that empty data is a perfectly valid scenario and given that
>other
> > matplotlib functions handle it gracefully, we should make the
> > collections object more friendly to empty data.
>
>I agree; a call with empty data should simply not plot anything.
>
>Eric
>
>
>Digging further, it appears that the problem is in _path.cpp for
>_path_module::affine_transform() which explicitly checks for an
>empty vertices array and throws an exception if it is empty.
>
>So, do we want to make _path.cpp empty-friendly or should we just
>make empty collections objects just avoid doing anything that
>requires doing an affine transform?
>
>Ben Root
>
>
>
> Ok, some more digging deepens the mystery.  While an empty-friendly
> _path.cpp would be nice, it appears that the collections and axes
> objects are already doing all it can to avoid doing transforms for
> empty
> collections.
>
> However, it appears that the supposedly empty collection object from
> scatter([], []) is not really empty.  Its self._paths member contains a
> list of unit_circle() from Path.  This is also the case for
> EllipseCollection.  Meanwhile, LineCollection and PatchCollection
> initializes their self._paths in accordance to their given data.
>

 One way to solve the problem would be to start each draw() method with a
 short-circuit return in case there is nothing to draw.  It would be needed
 only for classes for which empty self._paths is not a valid test.  So for
 CircleCollection it would be:

@allow_rasterization
def draw(self, renderer):
# sizes is the area of the circle circumscribing the polygon
# in points^2
if len(self._sizes) == 0:
return
self._transforms = [
transforms.Affine2D().scale(
(np.sqrt(x) * self.figure.dpi / 72.0) / np.sqrt(np.pi))
for x in self._sizes]
return Collection.draw(self, renderer)

 (Collection.draw returns nothing, so there is no inconsistency in the
 return value.)

 Alternatively, it looks like maybe an empty self._transforms could be
 used in a short-circuit test at the start of Collection.draw.

 Eric



> Ben Root
>
>

>>> That wouldn't completely solve the problem.  Affine transforms are being
>>> done for get_datalim() as well.  The other issue (and I see that I mixed
>>> this up myself) is the assumption elsewhere that a non-empty self._path
>>> attribute means that there is something to plot.  This is an assumption that
>>> is made in axes.py on line 1413 and it is an invalid assumption.
>>>
>>> As for your proposed solution in draw(), I prefer short-circuiting in
>>> Collections.draw().  This makes for less work for new Collection subclasses.
>>>
>>> Ben Root
>>>
>>
>>
>> Working from an assumption that we can't possibly find all bad/broken
>> assumptions in mpl, I decided to go the route of Eric and make the
>> Collections object a

Re: [matplotlib-devel] Empty scatter plot

[Eric Firing]

On 02/18/2011 08:26 AM, Benjamin Root wrote:
>
>
> On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root  > wrote:
>
> On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root  > wrote:
>
> On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root  > wrote:
>
>
>
> On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing
> mailto:efir...@hawaii.edu>> wrote:
>
> On 02/15/2011 08:50 AM, Benjamin Root wrote:
>
> On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root
> mailto:ben.r...@ou.edu>
> >>
> wrote:
>
> On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing
> mailto:efir...@hawaii.edu>
>  >> wrote:
>
> On 02/15/2011 07:40 AM, Benjamin Root wrote:
>  > I have come across a little inconsistency that
> was unexpected
> in the
>  > matplotlib API.  The following is perfectly valid:
>  >
>  > import matplotlib.pyplot as plt
>  > plt.plot([], [])
>  > plt.show()
>  >
>  >
>  > However, this is not valid:
>  >
>  > import matplotlib.pyplot as plt
>  > plt.scatter([], [])
>  > plt.show()
>  >
>  >
>  > The immediate issue that comes up in scatter is
> that it
> attempts to find
>  > min/max of the input data for the purpose of
> autoscaling
> (this can
>  > probably be done better by just using
> set_xmargin(0.05) and
>  > set_ymargin(0.05)).  This can easily be bypassed
> with an if
> statement.
>  > However, then we discover that polygon collection
> do not like
> having
>  > empty offsets, which leads to a failure in the affine
> transformation.
>  >
>  > So, the question is, is this a bug or a feature?  I
> personally believe
>  > that empty data is a perfectly valid scenario and
> given that
> other
>  > matplotlib functions handle it gracefully, we
> should make the
>  > collections object more friendly to empty data.
>
> I agree; a call with empty data should
> simply not plot anything.
>
> Eric
>
>
> Digging further, it appears that the problem is
> in _path.cpp for
> _path_module::affine_transform() which
> explicitly checks for an
> empty vertices array and throws an exception if
> it is empty.
>
> So, do we want to make _path.cpp empty-friendly
> or should we just
> make empty collections objects just avoid doing
> anything that
> requires doing an affine transform?
>
> Ben Root
>
>
>
> Ok, some more digging deepens the mystery.  While an
> empty-friendly
> _path.cpp would be nice, it appears that the
> collections and axes
> objects are already doing all it can to avoid doing
> transforms for empty
> collections.
>
> However, it appears that the supposedly empty
> collection object from
> scatter([], []) is not really empty.  Its
> self._paths member contains a
> list of unit_circle() from Path.  This is also the
> case for
> EllipseCollection.  Meanwhile, LineCollection and
> PatchCollection
> initializes their self._paths in accordance to their
> given data.
>
>
> One way to solve the problem would be to start each
> draw() method with a short-circuit return in case there
> is nothing to draw.  It would be needed only for cla

Re: [matplotlib-devel] Empty scatter plot

[Benjamin Root]

On Fri, Feb 18, 2011 at 1:17 PM, Eric Firing  wrote:

> On 02/18/2011 08:26 AM, Benjamin Root wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root > > wrote:
>>
>>On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root >> wrote:
>>
>>On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root >> wrote:
>>
>>
>>
>>On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing
>>mailto:efir...@hawaii.edu>> wrote:
>>
>>On 02/15/2011 08:50 AM, Benjamin Root wrote:
>>
>>On Tue, Feb 15, 2011 at 12:19 PM, Benjamin Root
>>mailto:ben.r...@ou.edu>
>>>>
>>
>>wrote:
>>
>>On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing
>>mailto:efir...@hawaii.edu>
>>>
>>>> wrote:
>>
>>On 02/15/2011 07:40 AM, Benjamin Root wrote:
>> > I have come across a little inconsistency that
>>was unexpected
>>in the
>> > matplotlib API.  The following is perfectly valid:
>> >
>> > import matplotlib.pyplot as plt
>> > plt.plot([], [])
>> > plt.show()
>> >
>> >
>> > However, this is not valid:
>> >
>> > import matplotlib.pyplot as plt
>> > plt.scatter([], [])
>> > plt.show()
>> >
>> >
>> > The immediate issue that comes up in scatter is
>>that it
>>attempts to find
>> > min/max of the input data for the purpose of
>>autoscaling
>>(this can
>> > probably be done better by just using
>>set_xmargin(0.05) and
>> > set_ymargin(0.05)).  This can easily be bypassed
>>with an if
>>statement.
>> > However, then we discover that polygon collection
>>do not like
>>having
>> > empty offsets, which leads to a failure in the
>> affine
>>transformation.
>> >
>> > So, the question is, is this a bug or a feature?  I
>>personally believe
>> > that empty data is a perfectly valid scenario and
>>given that
>>other
>> > matplotlib functions handle it gracefully, we
>>should make the
>> > collections object more friendly to empty data.
>>
>>I agree; a call with empty data should
>>simply not plot anything.
>>
>>Eric
>>
>>
>>Digging further, it appears that the problem is
>>in _path.cpp for
>>_path_module::affine_transform() which
>>explicitly checks for an
>>empty vertices array and throws an exception if
>>it is empty.
>>
>>So, do we want to make _path.cpp empty-friendly
>>or should we just
>>make empty collections objects just avoid doing
>>anything that
>>requires doing an affine transform?
>>
>>Ben Root
>>
>>
>>
>>Ok, some more digging deepens the mystery.  While an
>>empty-friendly
>>_path.cpp would be nice, it appears that the
>>collections and axes
>>objects are already doing all it can to avoid doing
>>transforms for empty
>>collections.
>>
>>However, it appears that the supposedly empty
>>collection object from
>>scatter([], []) is not really empty.  Its
>>self._paths member contains a
>>list of unit_circle() from Path.  This is also the
>>case for
>>EllipseCollection.  Meanwhile, LineCollection and
>>PatchCollection
>>initializes their self._paths in accordance to their
>>given data.
>>
>>
>>One way to solve the problem would be to start each
>>draw() method with a short-circuit

[matplotlib-devel] svn is frozen; github migration underway

[John Hunter]

I have removed everyone's commit access to the mpl svn server in
advance of the github migration, which is underway.  Darren will reply
when github is live.

svn is dead, long live github!

JDH

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Voronoi diagram

[Nicolas Rougier]

Hi all,


I did not see any voronoi diagram in matplotlib examples so I created a simple 
one from the available tri.Triangulation function (I hope I did not miss 
something evident).


Nicolas



#!/usr/bin/env python
# -
# Voronoi diagram from a list of points
# Copyright (C) 2011  Nicolas P. Rougier
#
# Distributed under the terms of the BSD License.
# -
import numpy as np
import matplotlib
import matplotlib.pyplot as plt


def circumcircle(P1, P2, P3):
''' 
Return center of the circle containing P1, P2 and P3

If P1, P2 and P3 are colinear, return None

Adapted from:
http://local.wasp.uwa.edu.au/~pbourke/geometry/circlefrom3/Circle.cpp
'''
delta_a = P2 - P1
delta_b = P3 - P2
if np.abs(delta_a[0]) <= 0.1 and np.abs(delta_b[1]) <= 0.1:
center_x = 0.5*(P2[0] + P3[0])
center_y = 0.5*(P1[1] + P2[1])
else:
aSlope = delta_a[1]/delta_a[0]
bSlope = delta_b[1]/delta_b[0]
if np.abs(aSlope-bSlope) <= 0.1:
return None
center_x= (aSlope*bSlope*(P1[1] - P3[1]) + bSlope*(P1[0] + P2 [0]) \
- aSlope*(P2[0]+P3[0]))/(2.*(bSlope-aSlope))
center_y = -(center_x - (P1[0]+P2[0])/2.)/aSlope + (P1[1]+P2[1])/2.
return center_x, center_y

def voronoi(X,Y):
''' Return line segments describing the voronoi diagram of X and Y '''
P = np.zeros((X.size+4,2))
P[:X.size,0], P[:Y.size,1] = X, Y
# We add four points at (pseudo) "infinity"
m = max(np.abs(X).max(), np.abs(Y).max())*1e5
P[X.size:,0] = -m, -m, +m, +m
P[Y.size:,1] = -m, +m, -m, +m
D = matplotlib.tri.Triangulation(P[:,0],P[:,1])
T = D.triangles
n = T.shape[0]
C = np.zeros((n,2))
for i in range(n):
C[i] = circumcircle(P[T[i,0]],P[T[i,1]],P[T[i,2]])
X,Y = C[:,0], C[:,1]
segments = []
for i in range(n):
for k in D.neighbors[i]:
if k != -1:
segments.append([(X[i],Y[i]), (X[k],Y[k])])
return segments

# -
if __name__ == '__main__':
P = np.random.random((2,256))
X,Y = P[0],P[1]
fig = plt.figure(figsize=(10,10))
axes = plt.subplot(1,1,1)
plt.scatter(X,Y, s=5)
segments = voronoi(X,Y)
lines = matplotlib.collections.LineCollection(segments, color='0.75')
axes.add_collection(lines)
plt.axis([0,1,0,1])
plt.show()


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svn is frozen; github migration underway

[Jarrod Millman]

On Fri, Feb 18, 2011 at 1:53 PM, John Hunter wrote:
> I have removed everyone's commit access to the mpl svn server in
> advance of the github migration, which is underway.  Darren will reply
> when github is live.

Excellent!  I am glad to see that all the core scipy-related projects
will soon be on github (scipy will move to github as soon as the 0.9
release is finalized).

I am sure you know about this; but just as a reminder, Matthew and
Fernando made a set of generic instruction for using git/github:
  https://github.com/matthew-brett/gitwash
The idea being that all the core projects share a standard set of
procedures for using git/github and adopting similar workflow
policies.  So far NumPy, IPython, and NIPY all use these instructions:

  https://github.com/numpy/numpy/tree/master/doc/source/dev/gitwash
  https://github.com/ipython/ipython/tree/master/docs/source/development/gitwash
  https://github.com/nipy/nipy/tree/master/doc/devel/guidelines/gitwash

If you want I am happy to take care of adding gitwash to the
matplotlib docs as soon as the move to git/github is done (and
generating a pull request).

Best,
Jarrod

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svn is frozen; github migration underway

[Darren Dale]

On Fri, Feb 18, 2011 at 8:16 PM, Jarrod Millman  wrote:
> On Fri, Feb 18, 2011 at 1:53 PM, John Hunter wrote:
>> I have removed everyone's commit access to the mpl svn server in
>> advance of the github migration, which is underway.  Darren will reply
>> when github is live.
>
> Excellent!  I am glad to see that all the core scipy-related projects
> will soon be on github (scipy will move to github as soon as the 0.9
> release is finalized).
>
> I am sure you know about this; but just as a reminder, Matthew and
> Fernando made a set of generic instruction for using git/github:
>  https://github.com/matthew-brett/gitwash
> The idea being that all the core projects share a standard set of
> procedures for using git/github and adopting similar workflow
> policies.  So far NumPy, IPython, and NIPY all use these instructions:
>
>  https://github.com/numpy/numpy/tree/master/doc/source/dev/gitwash
>  https://github.com/ipython/ipython/tree/master/docs/source/development/gitwash
>  https://github.com/nipy/nipy/tree/master/doc/devel/guidelines/gitwash
>
> If you want I am happy to take care of adding gitwash to the
> matplotlib docs as soon as the move to git/github is done (and
> generating a pull request).

Jarrod, that would be greatly appreciated.

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svn is frozen; github migration underway

[Darren Dale]

On Fri, Feb 18, 2011 at 4:53 PM, John Hunter  wrote:
> I have removed everyone's commit access to the mpl svn server in
> advance of the github migration, which is underway.  Darren will reply
> when github is live.
>
> svn is dead, long live github!

I just pushed the repositories up to github.com/matplotlib .

A few notes:

* Jarrod offered to contribute to the docs to describe the recommended
workflow. For the impatient:

  - Visit https://github.com/matplotlib/matplotlib and hit the "fork" button
  - clone the resulting repository, eg "git clone
g...@github.com:username/matplotlib.git"
  - make a new branch (git checkout -b new_feature) and hack away
  - don't merge upstream changes into your feature branch (it makes
the history graph look ugly)
  - when you are ready to have your changes merged upstream, push your
branch to your own repository at github
  - switch to that branch in your github profile, and select the "pull
request" button. This starts the code review process, which also gives
others a chance to inspect the git history graph before it gets merged
into the official mpl repo.

* python-3 support should happen in the matploltib-py3 repo, the
master branch in that repository contains Michael's changes from the
py3k svn branch, but rebased on top of the more recent changes to the
master branch in the main matplotlib repo.

Darren

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel