[matplotlib-devel] Showing class heirarchy with Sphinx?
I'm going through and preparing the transforms.py documentation for our new Sphinx setup. One of the things that's really important to document is the class heirarchy, but Sphinx doesn't appear to do that. I've looked at the Sphinx documentation and nothing comes up. I thought I'd check with this list first to see if I'm just missing something. Otherwise, I thought I would address this with the Sphinx folks to see what they would suggest. I think this would also be useful to have in the "artists" api documentation. For example, right now it isn't explicit that Line2D inherits from Artist. We can, I suppose, implement some sort of standard to always put the base classes in the docstring, but it would be nice to automate that. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Showing class heirarchy with Sphinx?
On Thursday 05 June 2008 08:19:47 am Michael Droettboom wrote: > I'm going through and preparing the transforms.py documentation for our > new Sphinx setup. One of the things that's really important to document > is the class heirarchy, but Sphinx doesn't appear to do that. I've > looked at the Sphinx documentation and nothing comes up. I thought I'd > check with this list first to see if I'm just missing something. > Otherwise, I thought I would address this with the Sphinx folks to see > what they would suggest. I think this would also be useful to have in > the "artists" api documentation. For example, right now it isn't > explicit that Line2D inherits from Artist. We can, I suppose, implement > some sort of standard to always put the base classes in the docstring, > but it would be nice to automate that. I think this would be worth asking about on sphinx-dev, it seems like an important feature for the autodoc extension. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] One-pixel gap sometimes appears between AxesImage and axis frame
Hi. When I generate an AxesImage with, say, imshow(array([[0, 1], [1, 0]])), a one-pixel gap sometimes appears between the image and the bottom and/or right edges of the axis frame. The gap is sometimes shaded, as if by anti-aliasing. The presence and shading of the gap depends on the axis size, figure size, and figure dpi. In particular, the gap comes and goes as I resize the figure. I've observed this using the WXAgg and TkAgg backends under matplotlib 0.98.0. I checked the trackers and mailing list archives but found no previous mention of this behavior. I looked into image.py but didn't readily see what might be responsible. Would someone in the know be willing to investigate? Many thanks in advance. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] RegularPolyCollection inputs in collections_demo.py are wrong?
I think the arguments for RegularPolyCollection were changed from 0.91.x to 0.98.0, but the example in collections_demo.py were not changed. -Tony Index: examples/api/collections_demo.py === --- examples/api/collections_demo.py(revision 5400) +++ examples/api/collections_demo.py(working copy) @@ -86,7 +86,7 @@ a = fig.add_subplot(2,2,3) -col = collections.RegularPolyCollection(fig.dpi, 7, +col = collections.RegularPolyCollection(7, sizes = N.fabs(xx)*10.0, offsets=xyo, transOffset=a.transData) trans = transforms.Affine2D().scale(fig.dpi/72.0) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] One-pixel gap sometimes appears between AxesImage and axis frame
This happens because the axes rectangle is rounded to the nearest pixels by (essentially, hand-waving over the details) doing (int)x0, (int)y0, (int)x1, (int)y1 where x0, y0, x1, y1 are the bounds of the box, whereas images are rounded to the nearest pixels by: (int)x0, (int)y0, (int)x0 + (int)width, (int)y0 + (int)height This should be fixable, but the implementation details make it a little tricky. I'm looking into this and will get back to you. Cheers, Mike Stan West wrote: > Hi. When I generate an AxesImage with, say, imshow(array([[0, 1], [1, > 0]])), a one-pixel gap sometimes appears between the image and the bottom > and/or right edges of the axis frame. The gap is sometimes shaded, as if by > anti-aliasing. The presence and shading of the gap depends on the axis > size, figure size, and figure dpi. In particular, the gap comes and goes as > I resize the figure. I've observed this using the WXAgg and TkAgg backends > under matplotlib 0.98.0. > > I checked the trackers and mailing list archives but found no previous > mention of this behavior. > > I looked into image.py but didn't readily see what might be responsible. > Would someone in the know be willing to investigate? Many thanks in > advance. > > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RegularPolyCollection inputs in collections_demo.py are wrong?
On Thu, Jun 5, 2008 at 11:02 AM, Tony Yu <[EMAIL PROTECTED]> wrote: > I think the arguments for RegularPolyCollection were changed from > 0.91.x to 0.98.0, but the example in collections_demo.py were not > changed. Thanks Tony, I committed this. Michael, when looking over the collection and scatter code to see what had replaced this dpi setting, I saw this in Axes.scatter: # MGDTODO: This has dpi problems # rescale verts rescale = np.sqrt(max(verts[:,0]**2+verts[:,1]**2)) verts /= rescale Do we need to revisit the dpi scaling in this function or is this comment stale? JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RegularPolyCollection inputs in collections_demo.py are wrong?
It's still a problem. It takes the dpi at the time of plot building and uses that to scale each of the objects. I have followed the example of RegularPolyCollection and now do this scaling during draw. There was another dpi-related bug that affected the example only: trans = transforms.Affine2D().scale(fig.dpi/72.0) Obviously hard-codes the dpi at plot-building time. This will be dynamic: trans = fig.dpi_scale_trans + transforms.Affine2D().scale(1.0/72.0) I'll commit these to SVN shortly. Cheers, Mike John Hunter wrote: > On Thu, Jun 5, 2008 at 11:02 AM, Tony Yu <[EMAIL PROTECTED]> wrote: > >> I think the arguments for RegularPolyCollection were changed from >> 0.91.x to 0.98.0, but the example in collections_demo.py were not >> changed. >> > > Thanks Tony, > > I committed this. Michael, when looking over the collection and > scatter code to see what had replaced this dpi setting, I saw this in > Axes.scatter: > > > # MGDTODO: This has dpi problems > # rescale verts > rescale = np.sqrt(max(verts[:,0]**2+verts[:,1]**2)) > verts /= rescale > > Do we need to revisit the dpi scaling in this function or is this comment > stale? > > JDH > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RegularPolyCollection inputs in collections_demo.py are wrong?
On Thu, Jun 5, 2008 at 12:02 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Obviously hard-codes the dpi at plot-building time. This will be dynamic: > > trans = fig.dpi_scale_trans + transforms.Affine2D().scale(1.0/72.0) Alternatively you can connect to the figure dpi_changed event -- there is an example in Axes.cla Thanks, JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] CSS changes in Sphinx docs
I added some custom CSS to our Sphinx HTML builds to add thin grey lines above each class, method and function definition. I was finding it very hard to visually see where each block of documentation begins. You may need to blitz your documentation build directory for this to work. If others don't like this, I can remove it. It gets the ball rolling on other CSS changes we want to make, though I suspect we want to keep them to a minimum, as the Sphinx defaults are already pretty good. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
I'm not entirely certain this is desirable behavior -- what if the user
*wants* to draw an open-yet-filled polygon? How could that be done?
(Admittedly, it couldn't be done before). It seems more general to
require the user to close polygons.
This change occurred as part of the big push to draw everything as
polycurves. If we decide to support implicit closing of polygons, we
can probably do that within the polygon patch class.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> Brian F. has correctly pointed out a change in behavior from the
> maintenance branch to the trunk: in the former, the fill command does
> not require that the polygon be closed--that is, that the last point
> coincide with the first. Hence, a filled rectangle can be specified
> with a list of 4 points. This seems to me like desirable behavior.
> After a very cursory look I have not spotted any obvious place where
> this change occurred, but I suspect it will be immediately obvious to
> you.
>
> Should the old behavior be restored?
>
> Thanks.
>
> Eric
>
>
>
> Subject:
> Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0
> From:
> Bryan Fodness <[EMAIL PROTECTED]>
> Date:
> Thu, 05 Jun 2008 08:38:59 -0400
> To:
> Eric Firing <[EMAIL PROTECTED]>
>
> To:
> Eric Firing <[EMAIL PROTECTED]>
> CC:
> Matplotlib <[EMAIL PROTECTED]>
>
>
> It seems like it does not connect the last point to the first point.
> This also happens with the matplotlib.patches Polygon.
>
>
> from pylab import fill, xlim, ylim, savefig
> x1, x2, y1, y2 = -4, 4, -4, 4
> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
> xlim(-5,5)
> ylim(-5,5)
> savefig('edge_test')
>
>
> On Thu, Jun 5, 2008 at 1:18 AM, Eric Firing <[EMAIL PROTECTED]
> > wrote:
>
> Bryan Fodness wrote:
>
> I just upgraded to 0.98.0 and recreated a few graphs. I am
> missing parts of the edges of a fill and polygon. Any
> suggestions?
>
>
> Please post an illustrative script, as simple as possible.
>
> Eric
>
>
>
>
> --
> "The game of science can accurately be described as a never-ending
> insult to human intelligence." - João Magueijo
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
BTW: Here's a patch if we decide to go that way:
Index: lib/matplotlib/patches.py
===
--- lib/matplotlib/patches.py (revision 5401)
+++ lib/matplotlib/patches.py (working copy)
@@ -540,6 +540,8 @@
See Patch documentation for additional kwargs
"""
Patch.__init__(self, **kwargs)
+xy = np.asarray(xy, np.float_)
+xy = np.concatenate([xy, [xy[0]]])
self._path = Path(xy)
__init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
Eric Firing wrote:
> Mike,
>
> Brian F. has correctly pointed out a change in behavior from the
> maintenance branch to the trunk: in the former, the fill command does
> not require that the polygon be closed--that is, that the last point
> coincide with the first. Hence, a filled rectangle can be specified
> with a list of 4 points. This seems to me like desirable behavior.
> After a very cursory look I have not spotted any obvious place where
> this change occurred, but I suspect it will be immediately obvious to
> you.
>
> Should the old behavior be restored?
>
> Thanks.
>
> Eric
>
>
>
> Subject:
> Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0
> From:
> Bryan Fodness <[EMAIL PROTECTED]>
> Date:
> Thu, 05 Jun 2008 08:38:59 -0400
> To:
> Eric Firing <[EMAIL PROTECTED]>
>
> To:
> Eric Firing <[EMAIL PROTECTED]>
> CC:
> Matplotlib <[EMAIL PROTECTED]>
>
>
> It seems like it does not connect the last point to the first point.
> This also happens with the matplotlib.patches Polygon.
>
>
> from pylab import fill, xlim, ylim, savefig
> x1, x2, y1, y2 = -4, 4, -4, 4
> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
> xlim(-5,5)
> ylim(-5,5)
> savefig('edge_test')
>
>
> On Thu, Jun 5, 2008 at 1:18 AM, Eric Firing <[EMAIL PROTECTED]
> > wrote:
>
> Bryan Fodness wrote:
>
> I just upgraded to 0.98.0 and recreated a few graphs. I am
> missing parts of the edges of a fill and polygon. Any
> suggestions?
>
>
> Please post an illustrative script, as simple as possible.
>
> Eric
>
>
>
>
> --
> "The game of science can accurately be described as a never-ending
> insult to human intelligence." - João Magueijo
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
Michael Droettboom wrote:
> I'm not entirely certain this is desirable behavior -- what if the user
> *wants* to draw an open-yet-filled polygon? How could that be done?
> (Admittedly, it couldn't be done before). It seems more general to
> require the user to close polygons.
True. I don't feel strongly about this. My guess is that at least at
the level of the Axes.fill method, a user would almost never want the
open-yet-filled case, but I could be guessing wrong, or the "almost"
qualifier could be critical. We could do automatic closing only at that
level, however.
Maybe the best alternative is to leave the trunk behavior as it is, and
make sure the documentation is very explicit about the need to supply a
closed path. This change could be added to API_CHANGES, as well as to
the Axes.fill docstring.
Does anyone know how Matlab, IDL, etc. handle this?
Eric
>
> This change occurred as part of the big push to draw everything as
> polycurves. If we decide to support implicit closing of polygons, we
> can probably do that within the polygon patch class.
>
> Cheers,
> Mike
>
> Eric Firing wrote:
>> Mike,
>>
>> Brian F. has correctly pointed out a change in behavior from the
>> maintenance branch to the trunk: in the former, the fill command does
>> not require that the polygon be closed--that is, that the last point
>> coincide with the first. Hence, a filled rectangle can be specified
>> with a list of 4 points. This seems to me like desirable behavior.
>> After a very cursory look I have not spotted any obvious place where
>> this change occurred, but I suspect it will be immediately obvious to
>> you.
>>
>> Should the old behavior be restored?
>>
>> Thanks.
>>
>> Eric
>>
>>
>>
>> Subject:
>> Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0
>> From:
>> Bryan Fodness <[EMAIL PROTECTED]>
>> Date:
>> Thu, 05 Jun 2008 08:38:59 -0400
>> To:
>> Eric Firing <[EMAIL PROTECTED]>
>>
>> To:
>> Eric Firing <[EMAIL PROTECTED]>
>> CC:
>> Matplotlib <[EMAIL PROTECTED]>
>>
>>
>> It seems like it does not connect the last point to the first point.
>> This also happens with the matplotlib.patches Polygon.
>>
>>
>> from pylab import fill, xlim, ylim, savefig
>> x1, x2, y1, y2 = -4, 4, -4, 4
>> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
>> xlim(-5,5)
>> ylim(-5,5)
>> savefig('edge_test')
>>
>>
>> On Thu, Jun 5, 2008 at 1:18 AM, Eric Firing <[EMAIL PROTECTED]
>> > wrote:
>>
>> Bryan Fodness wrote:
>>
>> I just upgraded to 0.98.0 and recreated a few graphs. I am
>> missing parts of the edges of a fill and polygon. Any
>> suggestions?
>>
>>
>> Please post an illustrative script, as simple as possible.
>>
>> Eric
>>
>>
>>
>>
>> --
>> "The game of science can accurately be described as a never-ending
>> insult to human intelligence." - João Magueijo
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
Eric Firing wrote: > Michael Droettboom wrote: >> I'm not entirely certain this is desirable behavior -- what if the user >> *wants* to draw an open-yet-filled polygon? How could that be done? >> (Admittedly, it couldn't be done before). It seems more general to >> require the user to close polygons. > > True. I don't feel strongly about this. My guess is that at least at > the level of the Axes.fill method, a user would almost never want the > open-yet-filled case, but I could be guessing wrong, or the "almost" > qualifier could be critical. We could do automatic closing only at that > level, however. > > Maybe the best alternative is to leave the trunk behavior as it is, and > make sure the documentation is very explicit about the need to supply a > closed path. This change could be added to API_CHANGES, as well as to > the Axes.fill docstring. > > Does anyone know how Matlab, IDL, etc. handle this? Here is the Matlab help text; matlab does automatically close the polygons: fill(X,Y,C) creates filled polygons from the data in X and Y with vertex color specified by C. C is a vector or matrix used as an index into the colormap. If C is a row vector, length(C) must equal size(X,2) and size(Y,2); if C is a column vector, length(C) must equal size(X,1) and size(Y,1). If necessary, fill closes the polygon by connecting the last vertex to the first. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
Thanks. That's a good argument to do the close for fill(). I'll wait a bit to see if others chime in, but at least at that level it seems to be a no-brainer. Whether we want to do this in the Polygon patch is still an open question, perhaps. Cheers, Mike Eric Firing wrote: > Eric Firing wrote: >> Michael Droettboom wrote: >>> I'm not entirely certain this is desirable behavior -- what if the >>> user *wants* to draw an open-yet-filled polygon? How could that be >>> done? (Admittedly, it couldn't be done before). It seems more >>> general to require the user to close polygons. >> >> True. I don't feel strongly about this. My guess is that at least >> at the level of the Axes.fill method, a user would almost never want >> the open-yet-filled case, but I could be guessing wrong, or the >> "almost" qualifier could be critical. We could do automatic closing >> only at that level, however. >> >> Maybe the best alternative is to leave the trunk behavior as it is, >> and make sure the documentation is very explicit about the need to >> supply a closed path. This change could be added to API_CHANGES, as >> well as to the Axes.fill docstring. >> >> Does anyone know how Matlab, IDL, etc. handle this? > > Here is the Matlab help text; matlab does automatically close the > polygons: > > fill(X,Y,C) creates filled polygons from the data in X and Y with > vertex color specified by C. C is a vector or matrix used as an index > into the colormap. If C is a row vector, length(C) must equal > size(X,2) and size(Y,2); if C is a column vector, length(C) must equal > size(X,1) and size(Y,1). If necessary, fill closes the polygon by > connecting the last vertex to the first. > > Eric -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
Michael Droettboom wrote: > Thanks. That's a good argument to do the close for fill(). I'll wait a > bit to see if others chime in, but at least at that level it seems to be > a no-brainer. Whether we want to do this in the Polygon patch is still > an open question, perhaps. Mike, Let's see if anyone says anything either way. If no one does, then I suggest that you should be the one to decide whether it makes sense to make the change in patches or in fill. If the ultimate decision is to change patches, then that is simpler, and there is no point in making the slightly more complicated changes in axes. In either case, I think the closing should be done only if a test shows that the points passed in are not already closed. Looking at patches a little more, I think I would be inclined to put the change in Polygon, on the grounds that a polygon simply is a *closed* path specified by its vertices; there should be no need to explicitly close it, although it may be more efficient to do so. For the case where someone wants a general path, it looks like you have thoughtfully provided the PathPatch object, so we don't really lose generality by forcing the Polygon to be closed. Eric > > Cheers, > Mike > > Eric Firing wrote: >> Eric Firing wrote: >>> Michael Droettboom wrote: I'm not entirely certain this is desirable behavior -- what if the user *wants* to draw an open-yet-filled polygon? How could that be done? (Admittedly, it couldn't be done before). It seems more general to require the user to close polygons. >>> >>> True. I don't feel strongly about this. My guess is that at least >>> at the level of the Axes.fill method, a user would almost never want >>> the open-yet-filled case, but I could be guessing wrong, or the >>> "almost" qualifier could be critical. We could do automatic closing >>> only at that level, however. >>> >>> Maybe the best alternative is to leave the trunk behavior as it is, >>> and make sure the documentation is very explicit about the need to >>> supply a closed path. This change could be added to API_CHANGES, as >>> well as to the Axes.fill docstring. >>> >>> Does anyone know how Matlab, IDL, etc. handle this? >> >> Here is the Matlab help text; matlab does automatically close the >> polygons: >> >> fill(X,Y,C) creates filled polygons from the data in X and Y with >> vertex color specified by C. C is a vector or matrix used as an index >> into the colormap. If C is a row vector, length(C) must equal >> size(X,2) and size(Y,2); if C is a column vector, length(C) must equal >> size(X,1) and size(Y,1). If necessary, fill closes the polygon by >> connecting the last vertex to the first. >> >> Eric > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0]
I've gone ahead and fixed this in the Polygon patch. As you point out, if someone wants an open polygon, they can use PathPatch, and Polygon was never able to do that before anyway. Cheers, Mike Eric Firing wrote: > Michael Droettboom wrote: >> Thanks. That's a good argument to do the close for fill(). I'll >> wait a bit to see if others chime in, but at least at that level it >> seems to be a no-brainer. Whether we want to do this in the Polygon >> patch is still an open question, perhaps. > > Mike, > > Let's see if anyone says anything either way. If no one does, then I > suggest that you should be the one to decide whether it makes sense to > make the change in patches or in fill. If the ultimate decision is to > change patches, then that is simpler, and there is no point in making > the slightly more complicated changes in axes. In either case, I > think the closing should be done only if a test shows that the points > passed in are not already closed. > > Looking at patches a little more, I think I would be inclined to put > the change in Polygon, on the grounds that a polygon simply is a > *closed* path specified by its vertices; there should be no need to > explicitly close it, although it may be more efficient to do so. For > the case where someone wants a general path, it looks like you have > thoughtfully provided the PathPatch object, so we don't really lose > generality by forcing the Polygon to be closed. > > Eric > > > >> >> Cheers, >> Mike >> >> Eric Firing wrote: >>> Eric Firing wrote: Michael Droettboom wrote: > I'm not entirely certain this is desirable behavior -- what if the > user *wants* to draw an open-yet-filled polygon? How could that > be done? (Admittedly, it couldn't be done before). It seems more > general to require the user to close polygons. True. I don't feel strongly about this. My guess is that at least at the level of the Axes.fill method, a user would almost never want the open-yet-filled case, but I could be guessing wrong, or the "almost" qualifier could be critical. We could do automatic closing only at that level, however. Maybe the best alternative is to leave the trunk behavior as it is, and make sure the documentation is very explicit about the need to supply a closed path. This change could be added to API_CHANGES, as well as to the Axes.fill docstring. Does anyone know how Matlab, IDL, etc. handle this? >>> >>> Here is the Matlab help text; matlab does automatically close the >>> polygons: >>> >>> fill(X,Y,C) creates filled polygons from the data in X and Y with >>> vertex color specified by C. C is a vector or matrix used as an >>> index into the colormap. If C is a row vector, length(C) must equal >>> size(X,2) and size(Y,2); if C is a column vector, length(C) must >>> equal size(X,1) and size(Y,1). If necessary, fill closes the polygon >>> by connecting the last vertex to the first. >>> >>> Eric >> > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mathtext error
I'm getting an error with a mathtext string from the mathtext_examples:
import matplotlib.pyplot as plt
ax = plt.subplot(111)
s = r"$W^{3\beta}_{\delta_1 \rho_1 \sigma_2} = U^{3\beta}_{\delta_1
\rho_1} + \frac{1}{8 \pi 2} \int^{\alpha_2}_{\alpha_2} d
\alpha^\prime_2 \left[\frac{ U^{2\beta}_{\delta_1 \rho_1} -
\alpha^\prime_2U^{1\beta}_{\rho_1 \sigma_2} }{U^{0\beta}_{\rho_1
\sigma_2}}\right]$"
ax.text(1, 2, s)
plt.show()
[EMAIL PROTECTED]:~> python tmp/qslogo.py
Traceback (most recent call last):
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py",
line 331, in expose_event
self._render_figure(self._pixmap, w, h)
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py",
line 75, in _render_figure
...snipsnip
loc,tokens = self.parseImpl( instring, preloc, doActions )
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyparsing.py",
line 2304, in parseImpl
raise ParseSyntaxException(pe)
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyparsing.py",
line 216, in __init__
super(ParseSyntaxException, self).__init__(
TypeError: super() argument 1 must be type, not classobj
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] size of pcolor boxes don't match X, Y input
When I plot a matrix using pcolor, the size of the boxes don't match the input (each box is off by about 10% from the input coordinates). I think the problem is caused by the new draw method in PolyCollection (added in revision 5403). If I revert to the previous version of collections.py, the boxes are displayed properly. The below script is a simple test case. It should print the corners of the boxes on integer coordinates, but (on my computer, at least), the corners do not land on integer values. :-Tony == N = 2 pts = np.arange(0, N+1) X, Y = np.meshgrid(pts, pts) col = plt.pcolor(X, Y, np.random.rand(N, N)) plt.show() - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building matplotlib on Windows
Stan, I am cc'ing the dev list for archival reasons. I prefer the VS2003 build for several reasons. It is faster to build. The resulting code is faster and smaller too. This is due to Microsoft's compiler just being better than gcc. The process is not necessarily easier either way though. I will try to outline the steps from memory here, but definitely check out the information in the header of setupext.py and in the zip win32_static* files. Tk backend: Install the latest 8.4 release of ActiveTCL into "C:\Tcl". GTK backend: Install the lastest 2.10 version of the win32 gtk dev package into "C: \GTK". You can get these here "http://sourceforge.net/projects/gladewin32/ ". gtk-2.12 does not work. Install the latest 2.10 versions of pygtk. GTK is a little off when it comes to pkg-config, so if you want the gtk backend I'll have to give you some more information. I am happy to do this, but it is late for me so I am just holding off right now. WX is native python now, so nothing special is needed. Obviously have numpy-1.1 installed. This setup is the same for python 2.4 and 2.5. Since you are going to be using svn, just extract the win32_static_vs.zip (for VS2003) in you matplotib folder. You should then have a win32_static folder in there. Building a package is as simple as: C:\Python25\python.exe setup.py build --compiler=msvc bdist_wininst or C:\Python25\python.exe setupegg.py build --compiler=msvc bdist_egg If you want to use mingw, that just involves installing mingw to "C: \mingw" and using the win32_static.zip instead of the vs version. Let me know how it goes, Charlie On Jun 5, 2008, at 1:28 PM, Stan West wrote: > Thank you for the prompt reply. I have both compilers and have little > preference between them at the outset. Are there significant > differences in > either the build process or the result that I should consider? > > > -Original Message- > From: Charlie Moad [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 05, 2008 12:30 > To: Stan West > Subject: Re: Building matplotlib on Windows > > I should first ask if you are planning to build with mingw or visual > studio > 2003? > > - Charlie > > On Thu, Jun 5, 2008 at 11:09 AM, Stan West <[EMAIL PROTECTED]> > wrote: >> Greetings. I gather from the matplotlib mailing lists that you're the >> expert on building it under Windows. I'd like to learn how to do that >> to benefit from bug-fixes. What's involved? I started gathering the >> dependencies mentioned in the COMPILING section of the INSTALL file. >> That lead me to setupext.py, which led me to win32_static, where I >> found files intended for Python 2.2 to 2.4. Figuring from that that >> some of the build information might be outdated, I decided to contact >> you directly and ask about the current state of things. I would >> appreciate > any help you can offer. >> >> Kind regards, >> >> Stan West, Ph.D. >> Research Physicist >> U.S. NAVAL RESEARCH LABORATORY >> > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] docs push
Darren has kick started a documentation effort in sphinx (which
resides in the doc subdir of the trunk) that is proving quite
successful. sphinx is ReST based, and is pretty easy to jump into.
As I understand it, Darren will have some time over the summer to
contribute to the effort (porting the existing docstrings in the API
documentation and the existing user's guide) but there is a lot to be
done. mpl has decent docs, certainly not great docs, and I'd like to
capitalize on the inertia Darren has created and try and strong arm
more of you into contributing to this effort. There is plenty to be
done, and even if you are no mpl expert there is lot you can
contribute.
I have organized a document in the developer's section
(doc/devel/outline.rst in the mpl src tree) listing units I think
would be good additions to the docs, suggesting authors in some cases
where I know someone is particularly well qualified, setting a status
field ("no author", "has author", "submitted", "complete") etc
There are lots of ? symbols, which means either that we have no
candidate, or that my designee has not accepted the designation. Eg,
I may have nominated Eric Firing for a section, but he hasn't yet
agreed to do it, so I put a ? by his name. When he agrees to do it,
he can remove the ? by his name in svn. Importantly, every section
has an editor, and these fields are currently mostly populated by ?.
The editor responsibility is pretty light: read the chapter, check it
for style and correctness, and sign off on it.
By no means do we need to go this route -- we can continue to
contribute as we can, which has worked well in the rest of the mpl
code base and is currently working well for the new docs. If you find
this excessively bureaucratic or onerous, I'm happy to shelve the
approach. This is mostly an attempt to get more people involved in
the documentation effort by making a pubic show of the work that we
needs to be done, with bite size pieces that pepole can sign on for,
and it is less of an effort to get a formal review process in place.
But docs are an area where an "editor" can make a significant
contribution with a fairly minimal effort, so I think having a review
is a good addition. I stress in the outline.rst doc::
It is probably easiest to be an editor. Once you have signed up to be
an editor, if you have an author, pester the author for a submission
every so often. If you don't have an author, find one, and then pester
them! Your only two responsibilities are getting your author to
produce and checking their work, so don't be shy. You *do not* need
to be an expert in the subject you are editing -- you should know
something about it and be willing to read, test, give feedback and
pester!
Included below is the outline.rst doc from the devel documentation.
Since a lot of email readers mangle the spacing, you can also consult
the mpl src in docs/devel/outline.rst or the html rendered version at
http://matplotlib.sourceforge.net/mpldocs/devel/outline.html or the
src online at
http://matplotlib.sourceforge.net/mpldocs/_sources/devel/outline.txt
.
Those of you who are developers can jump in and edit the outline doc,
assigning yourself, removing yourself, updating the status, etc...
Those of you who don't have commit rights but want to participate,
just respond here with author or editor positions you want and/or
submit a patch against the file. Also, I expect there are many
glaring holes in the topic list so do not be shy in making additions,
deletions or revisions.
JDH
outline.rst:
.. _outline:
Docs outline
Proposed chapters for the docs, who has responsibility for them, and
who reviews them. The "unit" doesn't have to be a full chapter
(though in some cases it will be), it may be a chapter or a section in
a chapter.
=== ===
===
User's guide unitAuthor Status Reviewer
=== ===
===
contouring Eric ? no authorPerry ?
quiver plots Eric ? no author?
quadmesh ?no author?
images ?no author?
histograms Manuel ? no author
Erik Tollerud ?
bar / errorbar ?no author?
x-y plots?no author?
time series plots?no author?
date plots John has author ?
working with dataJohn has author ?
custom ticking ?no author?
masked data Eric ? no author?
text ?
