matplotlib-devel Mailing List for matplotlib (Page 3)

> The length of that proposed keyword is a warning flag that it may also 
> be a bad design. Again, I would say either eliminate built-in support 
> for color-by-length, or implement it via "color='length'", and then 
> intercept that non-standard 'length' specification inside quiver so 
> that it never gets passed to the standard color-handling routines.
>
> Now that you have explained it, I am inclined to either do a quick-fix 
> of the present quiver so that it works again roughly as-is, or change 
> the example so that it does not use the undocumented(?) "color=True" 
> syntax; is one of these alternatives OK with you? Do you have a 
> preference? Or do you already have an improved version that we can 
> substitute now? One way or another, I don't want to leave a 
> non-functioning demo in svn.
I would remove it; if we want a quiver function with color as length, we 
could create a wrapper function to do that. I would lean towards making 
people generate their own color array based on the array length. I'm 
not going to have a new quiver anytime soon I think--a friend of mine 
today pointed out that matlab distorts quiver arrows just like 
matplotlib does. In matlab it isn't as noticable, however, since matlab 
impliments quiver as lines instead of as polygons. In the short term, 
I'm seriously tempted to just make matplotlib do the same.
Jordan

Jordan,
Thanks for the explanation. It makes some sense now, but doesn't 
impress me as a good API. Having color track arrow length does not seem 
to me to warrant its own special and slightly bizarre syntax 
("color=True"--completely non-intuitive). It would make more sense for 
the user to simply provide an array to be mapped; if the user wants that 
array to be the arrow length (hence redundant), the user can do that 
calculation and provide that array.
What I would like to see is a reconsideration of the API and 
corresponding docstring, as part of your massive re-write. This is a 
good opportunity to think about what would constitute a clean and 
consistent interface.
Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> I have committed changes in color handling that allow the collection 
>> initializers to accept the usual flexible mpl color specifications. 
>> Your message about quiver prompted me to try examples/quiver_demo.py, 
>> which is not run by backend_drivers.py, and which I had therefore not 
>> tested. It doesn't work now--and it doesn't make any sense to me, 
>> either. (E.g., what on earth is "color=True" supposed to mean?) That 
>> is, it is not clear to me what the quiver invocations in the demo are 
>> supposed to do based on the quiver doc string. The simplest quiver 
>> invocation works, but it looks to me like the argument handling beyond 
>> that is broken, and I don't think it is entirely the fault of my 
>> recent changes. I can help straighten it out, given a clear 
>> specification of what quiver is actually supposed to do with various 
>> argument combinations. Let me know if and when this would be useful.
> 
> I believe "color=True" is intended to give the arrows a color value 
> based upon the arrow length. Calling quiver with color=True fails 
> because looks_like_color( ) now treats True as a mistaken grey 
> specification; it raises a warning saying to enclose True in brackets. 
> quiver wants looks_like_color(True) to simply return a False.
Aha! This is an example of why we are deprecating float-as-grayscale.
> 
> for 'color' quiver appears to want either:
> 
> a) Something that looks_like_color(), in which case all arrows are that 
> color
> b) A True, in which case arrows are colored by length
> c) An array the same size as the first data array, in which case the 
> arrows are the colors specified in the array
> d) Anything else, which makes them black.
It also looks to me like the argument parsing can incorrectly interpret 
a scale factor as a color. Maybe this also used to work, but if so, it 
was at best fragile.
> 
> I don't know if this is a good use of color=... because I don't know how 
> uniform you want the matplotlib interface to be in its keyword use. We 
> could set up a "color_by_length=True" keyword for quiver that would 
> override the color setting, that would probably be my fix the problem.
The length of that proposed keyword is a warning flag that it may also 
be a bad design. Again, I would say either eliminate built-in support 
for color-by-length, or implement it via "color='length'", and then 
intercept that non-standard 'length' specification inside quiver so that 
it never gets passed to the standard color-handling routines.
Now that you have explained it, I am inclined to either do a quick-fix 
of the present quiver so that it works again roughly as-is, or change 
the example so that it does not use the undocumented(?) "color=True" 
syntax; is one of these alternatives OK with you? Do you have a 
preference? Or do you already have an improved version that we can 
substitute now? One way or another, I don't want to leave a 
non-functioning demo in svn.
Eric

Eric Firing wrote:
> I have committed changes in color handling that allow the collection 
> initializers to accept the usual flexible mpl color specifications. 
> Your message about quiver prompted me to try examples/quiver_demo.py, 
> which is not run by backend_drivers.py, and which I had therefore not 
> tested. It doesn't work now--and it doesn't make any sense to me, 
> either. (E.g., what on earth is "color=True" supposed to mean?) That 
> is, it is not clear to me what the quiver invocations in the demo are 
> supposed to do based on the quiver doc string. The simplest quiver 
> invocation works, but it looks to me like the argument handling beyond 
> that is broken, and I don't think it is entirely the fault of my 
> recent changes. I can help straighten it out, given a clear 
> specification of what quiver is actually supposed to do with various 
> argument combinations. Let me know if and when this would be useful.
I believe "color=True" is intended to give the arrows a color value 
based upon the arrow length. Calling quiver with color=True fails 
because looks_like_color( ) now treats True as a mistaken grey 
specification; it raises a warning saying to enclose True in brackets. 
quiver wants looks_like_color(True) to simply return a False.
for 'color' quiver appears to want either:
a) Something that looks_like_color(), in which case all arrows are that 
color
b) A True, in which case arrows are colored by length
c) An array the same size as the first data array, in which case the 
arrows are the colors specified in the array
d) Anything else, which makes them black.
I don't know if this is a good use of color=... because I don't know how 
uniform you want the matplotlib interface to be in its keyword use. We 
could set up a "color_by_length=True" keyword for quiver that would 
override the color setting, that would probably be my fix the problem.
Jordan

Jordan Dawe wrote:
> 
>>> This is probably what you want to do. You want to define your arrow
>>> in something like points, then do a rotation, and then apply one of
>>> the transformation offsets to place your arrow at an x,y location.
>>> Note there is a bug in some version of matplotlib in the affine code
>>> which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
>>> and be pointing NW and measure 2 inches from base to tip. The arrow
>>> size is independent of zoom and figure window size, which may or may
>>> not be desirable....
> 
> Ok, I've done a bunch of work on making quiver work without distorting 
> the arrows. I have a lot of questions. I've been playing with the 
> transforms functions all weekend and I still don't understand the 
> different transforms between figure, axes, and absolute space. Or how 
> to get access to the 'width' and 'height' Values that are mentioned in 
> the comments of transform.py.
> 
> The arrow size in quiver() should not be independent of zoom; it should 
> scale with the figure and axis size. Ideally by default quiver() should 
> ensure that the largest arrow doesn't overlap the 'gridbox' of the 
> arrows next to it. The problem is that in order to ensure the arrow is 
> rotated properly, the rotation must take place in absolute coordinates, 
> but the length scaling should take place in data coordinates. 
> Furthermore, the scaling should be a conditional: it should see if the x 
> or the y axis is most 'in danger' of having an arrow larger than its box 
> in data space, and then scale both the x and y coordinates equally in 
> absolute space to ensure the arrow isn't distorted. I'm not sure this 
> is even possible with Values; I think it would require at least a 
> greater_than BinOp, but I don't really understand all the transform 
> functionality or how to get access to it. Is there a way to do this?
> 
> After looking at all the files this weekend, I'm still not even sure 
> what matplotlib considers to be 'first-class' primitives. Is it 
> patches, lines, etc? What should a call to quiver() return? A list of 
> polygons? It's returning a collection in svn, but I don't think you can 
> set each object in a collection to a different transform. When should a 
> collection be used?
I think your questions here have two aspects. The first is, exactly 
what functionality should quiver have? I have always thought Matlab's 
quiver was ugly and fairly useless for my own purposes, so I don't 
advocate copying it. Have you written out a docstring or other 
specification of what quiver should do and what its API should be? The 
second part is, what should Axes plotting methods return? There are two 
styles: contour returns a whole ContourSet object; most (all?) other 
methods return only the Artists (e.g. a Line or a Collection.) When I 
changed contour to return the ContourSet, and more recently when I did a 
little reorganization of axes.py, John mentioned that it might be 
desirable to make other methods behave similarly, but I don't think 
there has been any more recent discussion, and I have not gotten back to 
it myself. Returning higher-level objects does fit in with moving more 
complicated functionality out of axes.py, which I would still like to 
do--eventually.
> 
> I don't know if I'm making any sense here; I'm fairly frustrated after a 
> weekend with little progress. Is there any hidden documentation that 
> could help me?
I made some scratch-paper notes for myself, but never considered my 
understanding complete, and it fades fast. Parts are covered quite well 
in the transforms.py docstring, but a good overview, clearly laying out 
the various coordinate systems (with a good naming convention) and where 
and how transformations are made would be a big help. This is something 
I might be able to work on, but it might not be very efficient for me to 
 do it. And I might not be able to do it fast enough to help with your 
present quivering.
Eric

Jordan,
I have committed changes in color handling that allow the collection 
initializers to accept the usual flexible mpl color specifications. 
Your message about quiver prompted me to try examples/quiver_demo.py, 
which is not run by backend_drivers.py, and which I had therefore not 
tested. It doesn't work now--and it doesn't make any sense to me, 
either. (E.g., what on earth is "color=True" supposed to mean?) That is, 
it is not clear to me what the quiver invocations in the demo are 
supposed to do based on the quiver doc string. The simplest quiver 
invocation works, but it looks to me like the argument handling beyond 
that is broken, and I don't think it is entirely the fault of my recent 
changes. I can help straighten it out, given a clear specification of 
what quiver is actually supposed to do with various argument 
combinations. Let me know if and when this would be useful.
Eric

>> This is probably what you want to do. You want to define your arrow
>> in something like points, then do a rotation, and then apply one of
>> the transformation offsets to place your arrow at an x,y location.
>> Note there is a bug in some version of matplotlib in the affine code
>> which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
>> and be pointing NW and measure 2 inches from base to tip. The arrow
>> size is independent of zoom and figure window size, which may or may
>> not be desirable....
Ok, I've done a bunch of work on making quiver work without distorting 
the arrows. I have a lot of questions. I've been playing with the 
transforms functions all weekend and I still don't understand the 
different transforms between figure, axes, and absolute space. Or how 
to get access to the 'width' and 'height' Values that are mentioned in 
the comments of transform.py.
The arrow size in quiver() should not be independent of zoom; it should 
scale with the figure and axis size. Ideally by default quiver() should 
ensure that the largest arrow doesn't overlap the 'gridbox' of the 
arrows next to it. The problem is that in order to ensure the arrow is 
rotated properly, the rotation must take place in absolute coordinates, 
but the length scaling should take place in data coordinates. 
Furthermore, the scaling should be a conditional: it should see if the x 
or the y axis is most 'in danger' of having an arrow larger than its box 
in data space, and then scale both the x and y coordinates equally in 
absolute space to ensure the arrow isn't distorted. I'm not sure this 
is even possible with Values; I think it would require at least a 
greater_than BinOp, but I don't really understand all the transform 
functionality or how to get access to it. Is there a way to do this?
After looking at all the files this weekend, I'm still not even sure 
what matplotlib considers to be 'first-class' primitives. Is it 
patches, lines, etc? What should a call to quiver() return? A list of 
polygons? It's returning a collection in svn, but I don't think you can 
set each object in a collection to a different transform. When should a 
collection be used?
I don't know if I'm making any sense here; I'm fairly frustrated after a 
weekend with little progress. Is there any hidden documentation that 
could help me?
Jordan

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
 >> def is_scalar(obj): try: obj+1 except TypeError: return False
 >> else: return True
 Jouni> This seems to have broken axes.legend(), which for some
 Jouni> reason calls flatten(handles), where handles contains
 Jouni> instances of classes like lines.Line2D, which fail the new
 Jouni> is_scalar test. I don't see why the list should need
 Jouni> flattening, except if the user passes in a non-flat list.
Oh, I see. Apparently is_scalar was a badly named function. I'm
going to temporarily revert to the old behavior and then do a cleanup
and rename later -- after testing this time :-)
JDH

John Hunter <jdh...@ac...> writes:
> I just looked in cbook and we did indeed have an is_scalar function
> but it looked broken so I replaced it with
>
> def is_scalar(obj):
> try: obj+1
> except TypeError: return False
> else: return True
This seems to have broken axes.legend(), which for some reason calls
flatten(handles), where handles contains instances of classes like
lines.Line2D, which fail the new is_scalar test. I don't see why the
list should need flattening, except if the user passes in a non-flat
list.
-- 
Jouni

>>>>> "Fernando" == Fernando Perez <fpe...@gm...> writes:
 Fernando> Sure, your call. Safety above convenience is a good
 Fernando> overall mantra.
There is a hybrid approach, but it gets away from the neat and tidy
approach suggested by Eric. If any of the args in the tuple are
greater than one, we could assume it is 0..255, else assume 0..1. But
I think consistency may trump convenience here.
JDH 

On 5/21/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Fernando" =3D=3D Fernando Perez <fpe...@gm...> writes:
>
> Fernando> (R,G,B).float_tuple -> floats in the 0...1 range
> Fernando> (R,G,B).int_tuple -> floats in the 0..255 range.
>
> My worry here is that it is pretty common to do something like
>
> red =3D 1,0,0
>
> which in your system would be interpreted as a int tuple and hence in
> the 0..255 range. It may be easier for people to divide by 255.0 when
> they have vals in the 0..255 range than it is for them to remember to
> use ints and float consistently.
Sure, your call. Safety above convenience is a good overall mantra.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <fpe...@gm...> writes:
 Fernando> (R,G,B).float_tuple -> floats in the 0...1 range
 Fernando> (R,G,B).int_tuple -> floats in the 0..255 range.
My worry here is that it is pretty common to do something like
 red = 1,0,0
which in your system would be interpreted as a int tuple and hence in
the 0..255 range. It may be easier for people to divide by 255.0 when
they have vals in the 0..255 range than it is for them to remember to
use ints and float consistently.
JDH

On 5/21/06, Eric Firing <ef...@ha...> wrote:
> Darren Dale wrote:
> > On Sunday 21 May 2006 15:26, John Hunter wrote:
> >
> >>>>>>>"Eric" =3D=3D Eric Firing <ef...@ha...> writes:
> >>
> >> Eric> Suggestion: we say, "A color can be specified as a string in
> >> Eric> any of the following formats: standard color abbreviations,
> >> Eric> html names, hex, or a floating point number between 0 and 1.
> >> Eric> Or it can be given as a sequence of three numbers specifying
> >> Eric> R,G,B on a scale from 0 to 1." Perfectly consistent and
> >> Eric> understandable, and clear in the code: "if
> >> Eric> is_string_like(c): convert it, else: pass it on as RGB.
> >> Eric> This consistency then makes it easy to distinguish between,
> >> Eric> and transparently handle, the case of a single color versus
> >> Eric> a sequence of colors.
> >>
> >>OK, you sold me. I hadn't thought it through to see it was either a
> >>string, RGB/A. I like the simplicity of this. So I'm +1 for your
> >>suggestion with a deprecation period where we check for a scalar
As a minor comment, for the sake of completeness wouldn't it be nice to all=
ow
(R,G,B).float_tuple -> floats in the 0...1 range
(R,G,B).int_tuple -> floats in the 0..255 range.
?
It's extremely common to see 0..255 specifications for colors.
Cheers,
f

Darren Dale wrote:
> On Sunday 21 May 2006 15:26, John Hunter wrote:
> 
>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>
>> Eric> Suggestion: we say, "A color can be specified as a string in
>> Eric> any of the following formats: standard color abbreviations,
>> Eric> html names, hex, or a floating point number between 0 and 1.
>> Eric> Or it can be given as a sequence of three numbers specifying
>> Eric> R,G,B on a scale from 0 to 1." Perfectly consistent and
>> Eric> understandable, and clear in the code: "if
>> Eric> is_string_like(c): convert it, else: pass it on as RGB.
>> Eric> This consistency then makes it easy to distinguish between,
>> Eric> and transparently handle, the case of a single color versus
>> Eric> a sequence of colors.
>>
>>OK, you sold me. I hadn't thought it through to see it was either a
>>string, RGB/A. I like the simplicity of this. So I'm +1 for your
>>suggestion with a deprecation period where we check for a scalar
> 
> 
> For what its worth, I'll also drop my objection.
Thanks. I will proceed.
Eric

On Sunday 21 May 2006 15:26, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
> Eric> Suggestion: we say, "A color can be specified as a string in
> Eric> any of the following formats: standard color abbreviations,
> Eric> html names, hex, or a floating point number between 0 and 1.
> Eric> Or it can be given as a sequence of three numbers specifying
> Eric> R,G,B on a scale from 0 to 1." Perfectly consistent and
> Eric> understandable, and clear in the code: "if
> Eric> is_string_like(c): convert it, else: pass it on as RGB.
> Eric> This consistency then makes it easy to distinguish between,
> Eric> and transparently handle, the case of a single color versus
> Eric> a sequence of colors.
>
> OK, you sold me. I hadn't thought it through to see it was either a
> string, RGB/A. I like the simplicity of this. So I'm +1 for your
> suggestion with a deprecation period where we check for a scalar
For what its worth, I'll also drop my objection.
Darren

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Suggestion: we say, "A color can be specified as a string in
 Eric> any of the following formats: standard color abbreviations,
 Eric> html names, hex, or a floating point number between 0 and 1.
 Eric> Or it can be given as a sequence of three numbers specifying
 Eric> R,G,B on a scale from 0 to 1." Perfectly consistent and
 Eric> understandable, and clear in the code: "if
 Eric> is_string_like(c): convert it, else: pass it on as RGB.
 Eric> This consistency then makes it easy to distinguish between,
 Eric> and transparently handle, the case of a single color versus
 Eric> a sequence of colors.
OK, you sold me. I hadn't thought it through to see it was either a
string, RGB/A. I like the simplicity of this. So I'm +1 for your
suggestion with a deprecation period where we check for a scalar
I just looked in cbook and we did indeed have an is_scalar function
but it looked broken so I replaced it with
def is_scalar(obj):
 try: obj+1
 except TypeError: return False
 else: return True
As for looks_like_color, I never use it (in fact was not aware of it
til you mentioned it). I think a function "is_colorlike" is a
potentially useful function, but as you say it is best implemented
with duck typing, something like
def is_colorlike(x):
 try: colorConverter.to_rgba(x)
 except: return False
 else: return True
JDH
 

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> Eric> John, I think all the ambiguity that you mention below comes
> Eric> from one source: the use of a single float to indicate a
> Eric> greyscale. Do we really need this? It is not supported by
> Eric> colors.looks_like_color(). It could be replaced by a string
> Eric> representation of the float (e.g., '0.75') or by a more
> Eric> specific string, such as 'g0.75' or 'grey0.75'. I think
> Eric> this would be a big net gain for mpl. We lose a lot of
> Eric> flexibility, convenience, and consistency by allowing the
> Eric> float-is-grey form.
> 
> this is a bug in looks_like_color -- ColorConverter, for example,
> supports it.
I suspect that all support of this form does occur via ColorConverter; 
it is interesting that the looks_like_color bug has not caused 
objections. looks_like_color is used in only two places: Axes.quiver, 
which therefore does not support the present float-as-grayscale form, 
and Collection._get_color. The consequence is that the collection rc 
settings also do not support float-as-grayscale, but nobody has noticed, 
or if they have, they have not been greatly bothered.
I also suspect that we should not have looks_like_color at all--it 
probably makes more sense to simply try to convert the object, and catch 
an exception if it is not convertable. If the object does look like a 
color, then chances are one wants to convert it anyway, so why go 
through most of the logic twice. (For compatibility, looks_like_color 
could simply do this--try to convert, return True on success and False 
on failure.)
> 
> What flexibility do we lose by supporting grayscale as float? As long
> as we have a policy of how we resolve ambiguity, I think we're OK.
Maybe OK, but not good. It is much better to avoid ambiguity entirely 
than to have to implement and explain an ambiguity resolution policy, 
when avoiding the ambiguity entails no loss in flexibility.
Present situation: we have to say something like, "(0.3, 0.4, 0.2) is a 
single RGB, but (0.3, 0.4) is a pair of greyscales". That's ugly and 
inconsistent, both from the users' standpoint and in terms of what it 
requires in the code.
Suggestion: we say, "A color can be specified as a string in any of the 
following formats: standard color abbreviations, html names, hex, or a 
floating point number between 0 and 1. Or it can be given as a sequence 
of three numbers specifying R,G,B on a scale from 0 to 1." Perfectly 
consistent and understandable, and clear in the code: "if 
is_string_like(c): convert it, else: pass it on as RGB. This 
consistency then makes it easy to distinguish between, and transparently 
handle, the case of a single color versus a sequence of colors.
(I posed everything in terms of RGB rather than RGBA, but the idea is 
the same.)
> Eg, ef we have a four-tuple of floats in a case where it could mean
> four grays or one RGB, we can choose to resolve it one way or the
> other. I think this is a corner case and wouldn't come up to often.
But when it does come up, sometimes the disambiguation will not do what 
the user expected. It is a fundamentally bad design, and it will bite 
people as long as it stays in place.
> As long as we have a way of disambiguating, eg adopting your 'g0.75'
> or 0.75' as a valid string, we retain flexibility and compatibility.
My proposal retains flexibility and increases simplicity and consistency 
by sacrificing the compatibility. I think this is a case where it is 
worth it to do so.
> 
> I also use the float-as-grayscale not too infrequently....
But maybe with a long deprecation period, you wouldn't terribly mind 
occasionally changing (0.2, 0.3) to ('0.2', '0.3')? (I know, it is easy 
for me because I am not the one who has to deal with it.)
Eric

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> slightly off-topic: Will mpl ever go 1.0? That's not meant
 Darren> to be flippant. I thought their was some pride in being
 Darren> beta.
I figured we would go to 1.0 when we run out of 0.88, 0.89, 0.90....
I think the API is pretty stable already, and suspect we won't be able
to guarantee much more stability after 1.0. Think about pygtk -- it
changed like a madman from 1.6 to 1.99 to 2.2 to 2.4... Sure, Numeric
was pretty stable after 10 years and 23 major releases, but then that
was broken with numarray and numpy. I'm not sure that API stability
above and beyond what we are already providing exists that much in the
wild, so 1.0 is probably more of a psychological landmark than
anything else. But maybe I'm just crazy.
I would like to fix the axis handling to be more flexible (eg, multiple
y axis lines per plot, detacable axis lines, etc) before 1.0. 
JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> John, I think all the ambiguity that you mention below comes
 Eric> from one source: the use of a single float to indicate a
 Eric> greyscale. Do we really need this? It is not supported by
 Eric> colors.looks_like_color(). It could be replaced by a string
 Eric> representation of the float (e.g., '0.75') or by a more
 Eric> specific string, such as 'g0.75' or 'grey0.75'. I think
 Eric> this would be a big net gain for mpl. We lose a lot of
 Eric> flexibility, convenience, and consistency by allowing the
 Eric> float-is-grey form.
this is a bug in looks_like_color -- ColorConverter, for example,
supports it.
What flexibility do we lose by supporting grayscale as float? As long
as we have a policy of how we resolve ambiguity, I think we're OK.
Eg, ef we have a four-tuple of floats in a case where it could mean
four grays or one RGB, we can choose to resolve it one way or the
other. I think this is a corner case and wouldn't come up to often.
As long as we have a way of disambiguating, eg adopting your 'g0.75'
or 0.75' as a valid string, we retain flexibility and compatibility.
I also use the float-as-grayscale not too infrequently....
JDH

On Saturday 20 May 2006 15:47, Eric Firing wrote:
> Darren Dale wrote:
> > I have used floats to indicate color in many of my own scripts. I think
> > changing this would have a pretty big impact on the users.
> >
> > Darren
>
> Darren,
>
> Float as greyscale, right?
Yes, that's what I meant.
> Yes, I am concerned about breaking things, but maybe it is not too late
> to deprecate it, so that the transition could be made some time in the
> future. I think it is worth considering this carefully now, while we
> are still pre-1.0.
slightly off-topic: Will mpl ever go 1.0? That's not meant to be flippant. I 
thought their was some pride in being beta.
> >>John,
> >>
> >>I think all the ambiguity that you mention below comes from one source:
> >>the use of a single float to indicate a greyscale. Do we really need
> >>this? It is not supported by colors.looks_like_color(). It could be
> >>replaced by a string representation of the float (e.g., '0.75') or by a
> >>more specific string, such as 'g0.75' or 'grey0.75'. I think this would
> >>be a big net gain for mpl. We lose a lot of flexibility, convenience,
> >>and consistency by allowing the float-is-grey form.
> >>
> >>Eric
> >>
> >>John Hunter wrote:
> >>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> >>>
> >>> Eric> John, Collections would be easier to use if they did not
> >>> Eric> have the restriction (from the docstring):
> >>>
> >>> Eric> All color args to a collection are sequences of rgba
> >>> Eric> tuples
> >>>
> >>> Eric> It would be easy to remove this restriction; shall I do it,
> >>> Eric> or is there a reason to leave the restriction in place?
> >>> Eric> (The error message that results from violating the
> >>> Eric> restriction is not helpful, and it would be as easy to
> >>> Eric> remove the restriction as to improve the error handling.)
> >>>
> >>>I think it's fine to remove it, but note that you have to be careful
> >>>to avoid ambiguity. How would you interpret
> >>>
> >>> color = (0.25, 0.5, 0.75, 1.0)
> >>>
> >>>Is this one rgba color or 4 grayscales?
> >>>
> >>>Because mpl accepts lots of different types of args for colors, there
> >>>will probably be some ambiguous cases, thought these will be very rare
> >>>corner cases. Just document what the behavior is, and everyone should
> >>>be happy. I think you could do the same for the linewidths, etc. Eg
> >>>if scalar, interpret as a single linewidth for all elements of the
> >>>collection?
> >>>
> >>>Or were you intending to preserve the requirement that one pass
> >>>sequences, but allow versatile color args in the sequence?
> >>>
> >>>JDH
> >>
> >>-------------------------------------------------------
> >>Using Tomcat but need to do more? Need to support web services, security?
> >>Get stuff done quickly with pre-integrated technology to make your job
> >>easier
> >>Download IBM WebSphere Application Server v.1.0.1 based on Apache
> >> Geronimo
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >> _______________________________________________
> >>Matplotlib-devel mailing list
> >>Mat...@li...
> >>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Darren Dale wrote:
> I have used floats to indicate color in many of my own scripts. I think
> changing this would have a pretty big impact on the users.
> 
> Darren
Darren,
Float as greyscale, right?
Yes, I am concerned about breaking things, but maybe it is not too late 
to deprecate it, so that the transition could be made some time in the 
future. I think it is worth considering this carefully now, while we 
are still pre-1.0.
Eric
> 
> 
>>John,
>>
>>I think all the ambiguity that you mention below comes from one source:
>>the use of a single float to indicate a greyscale. Do we really need
>>this? It is not supported by colors.looks_like_color(). It could be
>>replaced by a string representation of the float (e.g., '0.75') or by a
>>more specific string, such as 'g0.75' or 'grey0.75'. I think this would
>>be a big net gain for mpl. We lose a lot of flexibility, convenience,
>>and consistency by allowing the float-is-grey form.
>>
>>Eric
>>
>>John Hunter wrote:
>>
>>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>>
>>>
>>> Eric> John, Collections would be easier to use if they did not
>>> Eric> have the restriction (from the docstring):
>>>
>>> Eric> All color args to a collection are sequences of rgba
>>> Eric> tuples
>>>
>>> Eric> It would be easy to remove this restriction; shall I do it,
>>> Eric> or is there a reason to leave the restriction in place?
>>> Eric> (The error message that results from violating the
>>> Eric> restriction is not helpful, and it would be as easy to
>>> Eric> remove the restriction as to improve the error handling.)
>>>
>>>I think it's fine to remove it, but note that you have to be careful
>>>to avoid ambiguity. How would you interpret
>>>
>>> color = (0.25, 0.5, 0.75, 1.0)
>>>
>>>Is this one rgba color or 4 grayscales?
>>>
>>>Because mpl accepts lots of different types of args for colors, there
>>>will probably be some ambiguous cases, thought these will be very rare
>>>corner cases. Just document what the behavior is, and everyone should
>>>be happy. I think you could do the same for the linewidths, etc. Eg
>>>if scalar, interpret as a single linewidth for all elements of the
>>>collection?
>>>
>>>Or were you intending to preserve the requirement that one pass
>>>sequences, but allow versatile color args in the sequence?
>>>
>>>JDH
>>
>>
>>
>>-------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job
>>easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Matplotlib-devel mailing list
>>Mat...@li...
>>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> 
> 

I have used floats to indicate color in many of my own scripts. I think
changing this would have a pretty big impact on the users.
Darren
> John,
>
> I think all the ambiguity that you mention below comes from one source:
> the use of a single float to indicate a greyscale. Do we really need
> this? It is not supported by colors.looks_like_color(). It could be
> replaced by a string representation of the float (e.g., '0.75') or by a
> more specific string, such as 'g0.75' or 'grey0.75'. I think this would
> be a big net gain for mpl. We lose a lot of flexibility, convenience,
> and consistency by allowing the float-is-grey form.
>
> Eric
>
> John Hunter wrote:
>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>
>>
>> Eric> John, Collections would be easier to use if they did not
>> Eric> have the restriction (from the docstring):
>>
>> Eric> All color args to a collection are sequences of rgba
>> Eric> tuples
>>
>> Eric> It would be easy to remove this restriction; shall I do it,
>> Eric> or is there a reason to leave the restriction in place?
>> Eric> (The error message that results from violating the
>> Eric> restriction is not helpful, and it would be as easy to
>> Eric> remove the restriction as to improve the error handling.)
>>
>> I think it's fine to remove it, but note that you have to be careful
>> to avoid ambiguity. How would you interpret
>>
>> color = (0.25, 0.5, 0.75, 1.0)
>>
>> Is this one rgba color or 4 grayscales?
>>
>> Because mpl accepts lots of different types of args for colors, there
>> will probably be some ambiguous cases, thought these will be very rare
>> corner cases. Just document what the behavior is, and everyone should
>> be happy. I think you could do the same for the linewidths, etc. Eg
>> if scalar, interpret as a single linewidth for all elements of the
>> collection?
>>
>> Or were you intending to preserve the requirement that one pass
>> sequences, but allow versatile color args in the sequence?
>>
>> JDH
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John,
I think all the ambiguity that you mention below comes from one source: 
the use of a single float to indicate a greyscale. Do we really need 
this? It is not supported by colors.looks_like_color(). It could be 
replaced by a string representation of the float (e.g., '0.75') or by a 
more specific string, such as 'g0.75' or 'grey0.75'. I think this would 
be a big net gain for mpl. We lose a lot of flexibility, convenience, 
and consistency by allowing the float-is-grey form.
Eric
John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> Eric> John, Collections would be easier to use if they did not
> Eric> have the restriction (from the docstring):
> 
> Eric> All color args to a collection are sequences of rgba
> Eric> tuples
> 
> Eric> It would be easy to remove this restriction; shall I do it,
> Eric> or is there a reason to leave the restriction in place?
> Eric> (The error message that results from violating the
> Eric> restriction is not helpful, and it would be as easy to
> Eric> remove the restriction as to improve the error handling.)
> 
> I think it's fine to remove it, but note that you have to be careful
> to avoid ambiguity. How would you interpret
> 
> color = (0.25, 0.5, 0.75, 1.0)
> 
> Is this one rgba color or 4 grayscales? 
> 
> Because mpl accepts lots of different types of args for colors, there
> will probably be some ambiguous cases, thought these will be very rare
> corner cases. Just document what the behavior is, and everyone should
> be happy. I think you could do the same for the linewidths, etc. Eg
> if scalar, interpret as a single linewidth for all elements of the
> collection?
> 
> Or were you intending to preserve the requirement that one pass
> sequences, but allow versatile color args in the sequence?
> 
> JDH

>>>>> "Robert" == Robert Brown <br...@uc...> writes:
 Robert> Legend() works great when you're using plot, but when you
 Robert> use errorbar the auto-generated legend seems to include
 Robert> bar and/or cap lines for the error bars, making it
 Robert> unusable.
 Robert> I fixed this once a long time ago by making the legend
 Robert> command skip any lines without labels. It was kind of a
 Robert> hack....
 Robert> Having installed the latest version on my new MacBook Pro,
 Robert> I found a better way to fix the problem too. In the
 Robert> errorbar method of Axes I added label='_nolegend_' to the
 Robert> plotting commands. If a developer would like to add it,
 Robert> here are my modified lines 1577-1580 and 1590-1593 of
 Robert> axes.py:
Done -- thanks!
svn revision 2401
JDH

Legend() works great when you're using plot, but when you use 
errorbar the auto-generated legend seems to include bar and/or cap 
lines for the error bars, making it unusable.
I fixed this once a long time ago by making the legend command skip 
any lines without labels. It was kind of a hack....
Having installed the latest version on my new MacBook Pro, I found a 
better way to fix the problem too. In the errorbar method of Axes I 
added label='_nolegend_' to the plotting commands. If a developer 
would like to add it, here are my modified lines 1577-1580 and 
1590-1593 of axes.py:
 barlines.extend( self.hlines(y, x, 
left,label='_nolegend_') )
 barlines.extend( self.hlines(y, x, 
right,label='_nolegend_') )
 caplines.extend( self.plot(left, y, '|', 
ms=2*capsize,label='_nolegend_') )
 caplines.extend( self.plot(right, y, '|', 
ms=2*capsize,label='_nolegend_') )
 barlines.extend( self.vlines(x, y, 
upper,label='_nolegend_' ) )
 barlines.extend( self.vlines(x, y, 
lower,label='_nolegend_' ) )
 caplines.extend( self.plot(x, lower, '_', 
ms=2*capsize,label='_nolegend_') )
 caplines.extend( self.plot(x, upper, '_', 
ms=2*capsize,label='_nolegend_') )
---------------------------------------------------
Robb Brown
Biomedical Engineering
University of Calgary
Calgary, Alberta, Canada

> Jordan> Here's a reference talking about the different coordinate
> Jordan> systems accessible in matplotlib:
>
> Jordan> http://www.scipy.org/Cookbook/Matplotlib/Transformations
>
> Jordan> I think what we need is to set the coordinate transform to
> Jordan> be in and absolute, instead of relative, coordinate
> Jordan> system, or to build one ourselves. But I don't know
> Jordan> enough about matplotlib's internals to know if this is
> Jordan> right. Comments?
>
> This is probably what you want to do. You want to define your arrow
> in something like points, then do a rotation, and then apply one of
> the transformation offsets to place your arrow at an x,y location.
> Note there is a bug in some version of matplotlib in the affine code
> which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
> and be pointing NW and measure 2 inches from base to tip. The arrow
> size is independent of zoom and figure window size, which may or may
> not be desirable....
> 
Wow, that's service. Yeah, that's almost exactly what we want... but 
you are right, it would be better if the arrow scaled with the figure 
size, but maintained it's aspect ratio. I'll try to play around with 
your example and figure out how to make it work. Thanks a lot.
Jordan