Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 7:57 PM, Michael Droettboom md...@stsci.edu wrote: On 02/16/2011 03:53 PM, John Hunter wrote: On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboommd...@stsci.edu 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
On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing 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 ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing efir...@hawaii.edu 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 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 as robust as possible. I have attached a patch that should enable empty scatter plots in matplotlib and enable empty Collections as well. This has not been fully tested yet. Please be brutal! Ben Root Heh, looks like that patch breaks the plotting of errorbars (the line connecting the center point to the error caps is missing). I will see about fixing that. Ben Root Nailed it! After much examination and analysis, I realized that the transforms and the backend
Re: [matplotlib-devel] Empty scatter plot
On 02/18/2011 08:26 AM, Benjamin Root wrote: On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing efir...@hawaii.edu 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 ben.r...@ou.edu mailto:ben.r...@ou.edu mailto:ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing efir...@hawaii.edu mailto:efir...@hawaii.edu mailto:efir...@hawaii.edu 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 classes for which empty self._paths is not a
Re: [matplotlib-devel] Empty scatter plot
On Fri, Feb 18, 2011 at 1:17 PM, Eric Firing efir...@hawaii.edu wrote: On 02/18/2011 08:26 AM, Benjamin Root wrote: On Thu, Feb 17, 2011 at 1:36 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 2:05 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 1:41 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 1:17 PM, Eric Firing efir...@hawaii.edu 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 ben.r...@ou.edu mailto:ben.r...@ou.edu mailto:ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Tue, Feb 15, 2011 at 11:54 AM, Eric Firing efir...@hawaii.edu mailto:efir...@hawaii.edu mailto:efir...@hawaii.edu 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 classes for which empty self._paths is not a valid test. So for
[matplotlib-devel] svn is frozen; github migration underway
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
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
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
On Fri, Feb 18, 2011 at 8:16 PM, Jarrod Millman mill...@berkeley.edu 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
On Fri, Feb 18, 2011 at 4:53 PM, John Hunter jdh2...@gmail.com 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
