Michael Droettboom wrote:
> 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
Hi Mike,
1) I think that there is a bug in the patch: xy is a (N,2) array and I
get an error message for the line
if len(xy) and xy[0] !=xy[-1]:
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
so, I think it should really be
if len(xy) and (xy[0] !=xy[-1]).any():
2) With this change the output hist doesn't look that good any more,
since it relies on the axes fill method. axes fill produced a filled
patch where the enclosing line was not closed (i.e. open at bottom of
the hist). So you could easily produce a nice unfilled step
line-histogram and I intended to make this the default behaviour for
hist(histtype='step'). Now the line gets closed which most users - I
guess - don't want to.
So maybe it is needed to have a keyword for the axes fill method to
control whether the patch should be closed or not.
Manuel
> 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
>
--
---------------------------------------
Manuel Metz ............ [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: [EMAIL PROTECTED]
Web: www.astro.uni-bonn.de/~mmetz
Phone: (+49) 228 / 73-3660
Fax: (+49) 228 / 73-3672
---------------------------------------
-------------------------------------------------------------------------
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
