[matplotlib-devel] New arrow implementation, proof of concept.
Hi Matplotlib devs I'm happily using this software. Have just always found your arrow implementation a bit strange, as it assumes equal axis. Here is a new, simple first draft of an arrow implementation, that does not assume equal axis. Feel free to use any of the code under your preferred license. Or comment, and I will keep working on it. An example is included in the file. Best Regards Troels Kofoed Jacobsen newarrow.py Description: application/python - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] numpy histogram 1.1 -> 1.2
Hi, while adding the step-histogram I learned about the change of numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good idea to switch to the new histogram, i.e. use "new=True". Indeed, this is required to be able to allow to give bin-edges, which is possible with MPL 0.91. However, while keeping API compatibility on the one hand by allowing to provide bin-edges, this step also breaks API compatibility since the definition of bins has changed: numpy 1.0.4 In [1]:from numpy import * In [2]:random.seed(18) In [3]:x = random.random(100) In [4]:histogram(x, bins=array([0,0.1,0.2])) Out[4]:(array([11, 11, 78]), array([ 0. , 0.1, 0.2])) numpy 1.1.0.dev5106' In [1]:from numpy import * In [2]:random.seed(18) In [3]:x = random.random(100) In [4]: histogram(x, bins=array([0,0.1,0.2]),new=True) Out[4]: (array([11, 11]), array([ 0. , 0.1, 0.2])) How should this be handled? Follow numpy, breaking API compatibility and point to the API change of histogram? Or keeping API compatibility with MPL0.91 and write a wrapper function? I would prefer the first option... Manuel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] numpy histogram 1.1 -> 1.2
Here's the link to the numpy wiki: http://projects.scipy.org/scipy/numpy/roadmap#Semanticchangeforhistogram Manuel Metz wrote: > Hi, >while adding the step-histogram I learned about the change of > numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good > idea to switch to the new histogram, i.e. use "new=True". Indeed, this > is required to be able to allow to give bin-edges, which is possible > with MPL 0.91. >However, while keeping API compatibility on the one hand by allowing > to provide bin-edges, this step also breaks API compatibility since the > definition of bins has changed: > > numpy 1.0.4 > > In [1]:from numpy import * > In [2]:random.seed(18) > In [3]:x = random.random(100) > In [4]:histogram(x, bins=array([0,0.1,0.2])) > Out[4]:(array([11, 11, 78]), array([ 0. , 0.1, 0.2])) > > numpy 1.1.0.dev5106' > > In [1]:from numpy import * > In [2]:random.seed(18) > In [3]:x = random.random(100) > In [4]: histogram(x, bins=array([0,0.1,0.2]),new=True) > Out[4]: (array([11, 11]), array([ 0. , 0.1, 0.2])) > > > How should this be handled? Follow numpy, breaking API compatibility and > point to the API change of histogram? Or keeping API compatibility with > MPL0.91 and write a wrapper function? > > I would prefer the first option... > > Manuel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] numpy histogram 1.1 -> 1.2
Manuel Metz wrote: > Hi, >while adding the step-histogram I learned about the change of > numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good > idea to switch to the new histogram, i.e. use "new=True". Indeed, this > is required to be able to allow to give bin-edges, which is possible > with MPL 0.91. >However, while keeping API compatibility on the one hand by allowing > to provide bin-edges, this step also breaks API compatibility since the > definition of bins has changed: > > numpy 1.0.4 > > In [1]:from numpy import * > In [2]:random.seed(18) > In [3]:x = random.random(100) > In [4]:histogram(x, bins=array([0,0.1,0.2])) > Out[4]:(array([11, 11, 78]), array([ 0. , 0.1, 0.2])) > > numpy 1.1.0.dev5106' > > In [1]:from numpy import * > In [2]:random.seed(18) > In [3]:x = random.random(100) > In [4]: histogram(x, bins=array([0,0.1,0.2]),new=True) > Out[4]: (array([11, 11]), array([ 0. , 0.1, 0.2])) > > > How should this be handled? Follow numpy, breaking API compatibility and > point to the API change of histogram? Or keeping API compatibility with > MPL0.91 and write a wrapper function? > > I would prefer the first option... I strongly agree. Eric > > Manuel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Mixed-mode rendering
Hi,
On trunk, there is mixed-mode rendering support built in to (at least) the
SVG and PDF backends, though there are no calls to start/stop_rasterizing()
that utilize the raster mode. I've implemented mode switching for
those backends,
and would appreciate feedback on what I've done.
There are two modes that might drive a switch to raster for some artists:
1. User-driven specification of known complex artitsts.
2. Automatic detection of artist complexity (by type or vertex count).
The first mode is what I coded up, so I'll discuss it below.
A list of artists to rasterize is passed as a draw_raster kwarg to savefig,
which percolates down into print_* in the backend-specific figure canvas.
When the backend's canvas creates a renderer, the draw_raster list is placed
as an attribute on the renderer instance. I figured that the renderer should
be responsible for transporting the list of artists needing rasterization,
since it's at the renderer level that pixel vs. vector matters.
The switch to/from raster mode was made in Axes.draw, where the artists for
each axes are looped over. In the artist loop, I check if the artist to be
rendered is listed in the draw_raster attribute on the renderer instance. If
so, the appropriate calls are made to start and stop rasterizing.
Sample usage:
f=pyplot.figure()
ax=f.add_subplot(111)
p,=ax.plot(range(10))
f.savefig('test.pdf', draw_raster=(p,))
svn diff at
http://www.deeplycloudy.com/20080503-matplotlib-mixed-mode-r5110.diff
Thanks,
Eric Bruning
Graduate Research Assistant, Meteorology, Univ. Oklahoma
As of 6/1/2008, Research Assoc., Univ. Maryland/CICS and NOAA/NESDIS/STAR
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
