matplotlib-devel Mailing List for matplotlib (Page 14)

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

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
> 

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

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 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 <bry...@gm...>
>> Date:
>> 2008年6月05日 08:38:59 -0400
>> To:
>> Eric Firing <ef...@ha...>
>>
>> To:
>> Eric Firing <ef...@ha...>
>> CC:
>> Matplotlib <Mat...@li...>
>>
>>
>> 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 <ef...@ha... 
>> <mailto:ef...@ha...>> 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 
> 

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 <bry...@gm...>
> Date:
> 2008年6月05日 08:38:59 -0400
> To:
> Eric Firing <ef...@ha...>
>
> To:
> Eric Firing <ef...@ha...>
> CC:
> Matplotlib <Mat...@li...>
>
>
> 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 <ef...@ha... 
> <mailto:ef...@ha...>> 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

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 <bry...@gm...>
> Date:
> 2008年6月05日 08:38:59 -0400
> To:
> Eric Firing <ef...@ha...>
>
> To:
> Eric Firing <ef...@ha...>
> CC:
> Matplotlib <Mat...@li...>
>
>
> 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 <ef...@ha... 
> <mailto:ef...@ha...>> 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

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

On Thu, Jun 5, 2008 at 12:02 PM, Michael Droettboom <md...@st...> 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

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 <ts...@gm...> 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
> Mat...@li...
> 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

On Thu, Jun 5, 2008 at 11:02 AM, Tony Yu <ts...@gm...> 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

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
> Mat...@li...
> 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

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)

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.

On Wed, Jun 4, 2008 at 7:11 PM, Chris Fuller <cf...@th...> wrote:
> The old "classic" toolbar is out of sync with some API updates.
> This is what I get when running embedding_in_gtk2.py (after tweaking to use
> the classic toolbar)
Hey Chris, I made a few changes to restore support for the classic
toolbar in svn. These will come out in the 0.98.1 bug fix release
(what version are you using?) I could port these back to the 0.91
maintenance release, which is also broken but it would take some
additional work. I don't think many people are using this because
noone has complained and it's been broken for a while. If you are on
0.98, drop the attached ticker.py in site/packages/matplotlib and
backend_gtk.py in site-packages/matplotlib/backends/ until the next
bugfix release comes out.
JDH

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.

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

The old "classic" toolbar is out of sync with some API updates.
This is what I get when running embedding_in_gtk2.py (after tweaking to use 
the classic toolbar)
Traceback (most recent call last):
 File "embedding_in_gtk2.py", line 39, in <module>
 toolbar = NavigationToolbar(canvas, win)
 File "c:\python25\lib\site-packages\matplotlib\backends\backend_gtk.py", 
line
746, in __init__
 default_type=self.canvas.get_default_filetype())
TypeError: __init__() got an unexpected keyword argument 'default_type'
and the diffs, after what seemed like the appropriate fixing:
for 0.91.2
0 % diff be_gtk_912.py be_gtk_912-fixd.py
738,739c738,739
< formats=self.canvas.get_supported_filetypes(),
< default_type=self.canvas.get_default_filetype())
---
> filetypes=self.canvas.get_supported_filetypes(),
> default_filetype=self.canvas.get_default_filetype())
for 0.98.0
0 % diff be_gtk_980.py be_gtk_980-fixd.py
745,746c745,746
< formats=self.canvas.get_supported_filetypes(),
< default_type=self.canvas.get_default_filetype())
---
> filetypes=self.canvas.get_supported_filetypes(),
> default_filetype=self.canvas.get_default_filetype())
Cheers
Chris Fuller
University of Minnesota

I was able to fix this without too much trouble, so I have committed it 
on the trunk.
Cheers,
Mike
Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> I see that this isn't a LaTeX error, but I think Tony's comment is 
>> still somewhat valid. Since mathtext's parser is a direct subset of 
>> LaTeX's, and since $$ is a syntax error in LaTeX, it also is in 
>> mathtext. (This is really a side effect of make such a direct copy 
>> of the parser, rather than a deliberate choice). We can probably add 
>> a workaround to the parser, but I personally don't have a problem 
>> with it raising an exception. It doesn't seem to be a very useful 
>> thing to be able to do. What's your use case?
>>
>
> There is an exception for $ $ which is valid LaTeX. I have no 
> particular usecase, I was just surprised by the exception. However I 
> imagine that there could be instances when you want to interpolate an 
> expression into a string but sometimes leave it empty, not that 
> compelling perhaps.
>
> /Jörgen
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Jun 4, 2008 at 12:01 PM, Ted Drain <ted...@jp...> wrote:
> Sorry - I don't think I was very clear in my email. Try this:
>
> import pylab as p
> p.plot( [] ()
> p.gca().xaxis_date()
> p.show()
I did understand that in your first post, but I was focusing more on
your comments about a better date class than this specific bug, but I
see how the a better class would solve this bug too. But we can work
around this -- I committed some changes to the branch and trunk which
checks to see if the datalim have been updated on the call to xaxis
date and if not it will choose a valid default date range for the date
and view lim, but leave the "ignore" setting in place so it won't
affect the autoscaling when you actually do add data. Hit it with
your standard battery of tests and let me know how it works.
Michael, in the process of adding support for this, I added a check to
the Axes.update_datalim to ignore empty lists
 def update_datalim(self, xys):
 if len(xys): return
but when I ran backend driver, I found a bug on contour_demo.py where
a non-iterable was being passed in for xys. I added a debug print
statement to update_datalim to print type(xys), and here is what I
got, along with the traceback
johnh@flag:svn> python ~/mpl/examples/pylab_examples/contour_demo.py
<type 'list'>
<type 'list'>
<type 'list'>
<type 'list'>
<type 'tuple'>
<type 'list'>
<type 'numpy.ndarray'>
<class 'matplotlib.transforms.Bbox'>
Traceback (most recent call last):
 File "/home/titan/johnh/mpl/examples/pylab_examples/contour_demo.py",
line 83, in ?
 CB = colorbar(CS, shrink=0.8, extend='both')
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 1179, in colorbar
 ret = gcf().colorbar(mappable, cax = cax, ax=ax, **kw)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 965, in colorbar
 cb = cbar.Colorbar(cax, mappable, **kw)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colorbar.py",
line 591, in __init__
 self.add_lines(CS)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colorbar.py",
line 612, in add_lines
 ColorbarBase.add_lines(self, CS.levels, tcolors, tlinewidths)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colorbar.py",
line 329, in add_lines
 self.ax.add_collection(col)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py",
line 1242, in add_collection
 self.update_datalim(collection.get_datalim(self.transData))
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py",
line 1313, in update_datalim
 if not len(xys): return
TypeError: len() of unsized object
So the collection.get_datalim is returning a transformed bbox and
passing this off to update_datalim. This is easy to work around by
adding an iterable(xys) check, which I did on the branch and the
trunk, but to be sure I am not masking a bug, I wanted to make sure
that this is what should be happening here. I would think we would
call update_datalim_bounds for a bbox....
Thanks,
JDH
JDH

Sorry - I don't think I was very clear in my email. Try this:
import pylab as p
p.plot( [] ()
p.gca().xaxis_date()
p.show()
While this is a silly example, we do a lot of embedding of plots in GUI's
and this does come up. Normal MPL mode is something like:
- get data
- plot data
- configure and format plot
But in an embedded GUI, it's much easier to write code like this:
- configure and format plot
- wait for data
- get data and plot
So we want to be able to create a plot widget and set all the options and
formatting we want to use on it. Then wait for data to arrive or be input
and plot it. The problem is that it turns out there are a lot of places
where autoscaling or other algorithms cause date formatting to fail w/ a
similar message about not being able to handle zero or negative numbers.
You can work around them if you know they're going to show up but it's
frustrating. It would be nice if date formatting could be applied to any
plot range and have it work.
I'll make some more concrete examples later - I think it's something we can
fix. I'd like to get a suite of examples that illustrate some of the
problems before I/we start thinking about possible solutions.
Ted
> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...] On Behalf Of
> John Hunter
> Sent: Tuesday, June 03, 2008 1:51 PM
> To: Ted Drain
> Cc: Matplotlib
> Subject: Re: [matplotlib-devel] date2num/num2date and ordinal date
> 
> On Tue, Jun 3, 2008 at 3:41 PM, Ted Drain <ted...@jp...>
> wrote:
> 
> > At some point in the future, I'll put a little test case together to
> show
> > how the problems w/ not supporting a zero date show up in embedded
> plots.
> 
> Actually, when you pass in python datetime objects to mpl, we use the
> units converter infrastructure to convert these under the hood using
> date2num. This is fairly easy to override in the units registry. If
> you provide a registry to do conversions, locators and formatters for
> julian dates, I can easily include it with an rc setting to make a
> configurable default.
> 
> The date interface is setup in the matplotlib.dates module with the
> following code -- all you have to do is provide a different converter
> and we can provide a hook
> 
> class DateConverter(units.ConversionInterface):
> 
> def axisinfo(unit):
> 'return the unit AxisInfo'
> if unit=='date':
> majloc = AutoDateLocator()
> majfmt = AutoDateFormatter(majloc)
> return units.AxisInfo(
> majloc = majloc,
> majfmt = majfmt,
> label='',
> )
> else: return None
> axisinfo = staticmethod(axisinfo)
> 
> def convert(value, unit):
> if units.ConversionInterface.is_numlike(value): return
> value
> return date2num(value)
> convert = staticmethod(convert)
> 
> def default_units(x):
> 'return the default unit for x or None'
> return 'date'
> default_units = staticmethod(default_units)
> 
> 
> units.registry[datetime.date] = DateConverter()
> units.registry[datetime.datetime] = DateConverter()
> 
> -----------------------------------------------------------------------
> --
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
Some more thoughts about hist():
A "range" parameter should be added and used in histogram()
A new histogram should get a new colour, just like plot() does
The "step" type should default to fill=False
Actually, personally I hardly ever use bar histograms at all, so if 
step-mode (unfilled) was made default I wouldn't complain...
And not directly related to hist():
I think the pan/zoom tool should be on by default when a new figure opens. 
As it is now, we always need to press some button no matter what we want 
to do. pan/zoom is a good guess (at least for me)!
Thanks all developers for creating what has become my default plotting 
tool! I will never leave the python shell again.
(from kitchen import coffee)
Cheers,
Olle

I see that this isn't a LaTeX error, but I think Tony's comment is still 
somewhat valid. Since mathtext's parser is a direct subset of LaTeX's, 
and since $$ is a syntax error in LaTeX, it also is in mathtext. (This 
is really a side effect of make such a direct copy of the parser, rather 
than a deliberate choice). We can probably add a workaround to the 
parser, but I personally don't have a problem with it raising an 
exception. It doesn't seem to be a very useful thing to be able to do. 
What's your use case?
Cheers,
Mike
Jörgen Stenarson wrote:
> Tony Yu skrev:
> 
>> On Jun 3, 2008, at 4:18 PM, Jörgen Stenarson wrote:
>> 
>>> using an empty mathtext "$$" in labels generates an exception. See
>>> example and traceback below.
>>> 
>> My guess is that this is a LaTeX error. If you enter $$ in a normal 
>> LaTeX document, you will get:
>>
>>
>> 
> I don't think so. I'm using mathtext i.e. matplotlibs own latex 
> interpreter. And I get the same error with $$ $$.
>
> /Jörgen
>
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> 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

Hi,
On Tue, Jun 3, 2008 at 10:59 PM, Jeff Whitaker <js...@fa...> wrote:
>
> There are alternate versions num2date and a date2num in basemap that handle
> arbitrary calendars (not just 'proleptic gregorian') and arbitrary reference
> times (not just 'days since 0001年01月01日 00:00:00'). The docstrings are at
> http://matplotlib.sourceforge.net/mpl_toolkits.basemap.basemap.html, down
> near the bottom of the page.
>
> I don't know if this addresses the problem you're talking about though...
I agree with you Jeff: your version of date2num (and num2date)
perfectly does the job.
Maybe the 'units' argument should defaults to 'days since 0001年01月01日'
for backward compatibility.
And maybe, as for the DateConverter, the 'unit' argument in
axis_info() and convert() should follow the CF conventions
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.2/cf-conventions.html#time-coordinate)
as Jeff's functions, and default_units() should return 'days since
0001年01月01日'.
>
> -Jeff
>
> --
> Jeffrey S. Whitaker Phone : (303)497-6313
> Meteorologist FAX : (303)497-6449
> NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
> 325 Broadway Office : Skaggs Research Cntr 1D-113
> Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
>
>
-- 
Stephane Raynaud

Mark Bakker wrote:
> I agree that the new logo looks nice, but I also think that
> Rob is right: When you see the logo you wouldn't know that
> we are talking about a general purpose plotting package.
> So the question is: are we going for looks over meaning?
> I guess the other way around would be terrible: choosing
> meaning over looks you are stuck with an ugly logo that
> carries the right message. So to me, looks it is,
I'm just happy the red-on-green is gone. My colorblind eyes thank whoever 
changed this.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco