matplotlib-devel Mailing List for matplotlib (Page 471)

John Hunter wrote:
>>>>>>"Christopher" == Christopher Barker <Chr...@no...> writes:
> 
> 
>     Christopher> John Hunter wrote:
>     >> mean "do the default".  The hack workaround we use here is to
>     >> set 'None' (the string) rather than None itself.  Ugly, yes.
> 
>     Christopher> and really, really prone to error. If you need to use
>     Christopher> a string, use something else, like perhaps
>     Christopher> "transparent"
> 
> How is it really prone to error -- I would think that if the user pass
> es 'None', the string, for a color arg, there aren't too many
> alternative meanings.

Right.  'None' means no color--don't draw it.  'Transparent' is longer, 
and conceptually closer to alpha=0.  The only potential error is typing 
'None' instead of None, or the reverse.  It could be confusing to a new 
user.

> 
>     >> The real root of the problem is that renderer.draw_polygon(gc,
>     >> rgbFace, tverts) is overloaded to support edge and face drawing
>     >> in one function call.
> 
>     Christopher> That's actually a good thing. I like to think of a
>     Christopher> polygon with a border a single object, and it can
>     Christopher> dome in handy if you want to do something like draw a
>     Christopher> polygon with a border that is
>     Christopher> semi-transparent. drawing the fill and the stroke
>     Christopher> independently doesn't work right.
[....]
> 
> You may be right -- it may be a good thing -- what we need is a clear
> way to say "edge on" or "face on".  One way is to figure out a way to
> do it with the color specification itself ('None' or something like
> it).  Another way is to add boolean flags to the gc object...

But the gc object is at a lower level, not exposed to the user, so 
something like "color='None'" or "linewidth=0" is needed in any case at 
the higher levels, isn't it?  Or were you thinking of adding another 
kwarg to the high-level functions, that would be passed down the line 
into the backend?  Something like draw=face|edge|both?

Now I see the problem with linewidth=0; it solves only half the problem, 
turning off the boundary rendering, but does not facilitate the reverse, 
leaving the interior unfilled but drawing the boundary.

Eric

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:

    Christopher> John Hunter wrote:
    >> mean "do the default".  The hack workaround we use here is to
    >> set 'None' (the string) rather than None itself.  Ugly, yes.

    Christopher> and really, really prone to error. If you need to use
    Christopher> a string, use something else, like perhaps
    Christopher> "transparent"

How is it really prone to error -- I would think that if the user pass
es 'None', the string, for a color arg, there aren't too many
alternative meanings.

    >> The real root of the problem is that renderer.draw_polygon(gc,
    >> rgbFace, tverts) is overloaded to support edge and face drawing
    >> in one function call.

    Christopher> That's actually a good thing. I like to think of a
    Christopher> polygon with a border a single object, and it can
    Christopher> dome in handy if you want to do something like draw a
    Christopher> polygon with a border that is
    Christopher> semi-transparent. drawing the fill and the stroke
    Christopher> independently doesn't work right. I was recently
    Christopher> messing around with this in Cairo, and it's a pain
    Christopher> int eh *&^, but it can be done right, but it's up to
    Christopher> the back-end to figure out how.

You may be right -- it may be a good thing -- what we need is a clear
way to say "edge on" or "face on".  One way is to figure out a way to
do it with the color specification itself ('None' or something like
it).  Another way is to add boolean flags to the gc object...

JDH

John Hunter wrote:
> mean "do the default".  The hack workaround we use here is to set
> 'None' (the string) rather than None itself.  Ugly, yes.  

and really, really prone to error. If you need to use a string, use 
something else, like perhaps "transparent"


> The real root of the problem is that
> 
>         renderer.draw_polygon(gc, rgbFace, tverts)
> 
> is overloaded to support edge and face drawing in one function call.

That's actually a good thing. I like to think of a polygon with a border 
a single object, and it can dome in handy if you want to do something 
like draw a polygon with a border that is semi-transparent. drawing the 
fill and the stroke independently doesn't work right. I was recently 
messing around with this in Cairo, and it's a pain int eh *&^, but it 
can be done right, but it's up to the back-end to figure out how.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Thursday 25 May 2006 14:30, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
>     Eric> I see only advantages and no disadvantages whatsoever to
>     Eric> this change; am I missing something?
>
> The only potential problem with this is that a linewidth=0 is
> postscript actually means something -- it tells the rendering device
> to draw the thinnest possible line.  The change you propose could
> potentially break some code where people are relying on this.  This
> would not be the end of the world as long as we announce it.

I would be surprised if anyone is relying on this behavior. I think I remember 
reading in a book on postscript that use of this feature is discouraged.

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
    Eric> I see only advantages and no disadvantages whatsoever to
    Eric> this change; am I missing something?

The only potential problem with this is that a linewidth=0 is
postscript actually means something -- it tells the rendering device
to draw the thinnest possible line.  The change you propose could
potentially break some code where people are relying on this.  This
would not be the end of the world as long as we announce it.

Alternatively, we could support 'None' for the facecolor and edgecolor.  This
is a little difficult, unfortunately, since None is overloaded to
mean "do the default".  The hack workaround we use here is to set
'None' (the string) rather than None itself.  Ugly, yes.  

The real root of the problem is that

        renderer.draw_polygon(gc, rgbFace, tverts)

is overloaded to support edge and face drawing in one function call.
This is a hold-over from the bad-old-days where pcolor and friends use
polygons for every face, and I wanted to save the function call by
putting both edge and face drawing in one call.

One might rather have at the Artist level

    if facecolor!='None': 
        gc.set_foreground(facecolor)
        renderer.draw_polygon(gc, tverts, fill=False)

    if edgecolor!='None'
        gc.set_foreground(edgecolor)
        renderer.draw_polygon(gc, tverts, fill=False)

or have booleans in the patch object if this is too ugly.

This is cleaner in my view than using linewidth=0 but I don't feel
strongly.  However, it would require changing *every* backend.  Argg

JDH

On Thursday 25 May 2006 14:07, Eric Firing wrote:
> Darren, John, et al.,
>
> At present it is impossible to render a patch with exactly the
> dimensions specified because a boundary is required.  Present
> workarounds include setting the boundary color to the face color and
> setting a small or zero linewidth.  This is inefficient--a line is being
> rendered when it is not wanted--and imprecise, because the result of a
> very thin or zero-width line depends on the backend and output device.

My understanding is that a zero-width line in postscript will be rendered as a 
line with thickness equal to the resolution of the device. So the behavior 
does vary across backends.

> I propose that the backends be changed so that for any patch-like object
> or collection, setting the boundary linewidth to zero suppresses
> rendering of the line.
>
> I see only advantages and no disadvantages whatsoever to this change; am
> I missing something?

I don't claim to be an authority, but I can't think of any problems this might 
raise. Probably it could be done in the ps backend by simply wrapping the 
stroke commands in a check for zero line width. 

> If the proposal meets approval, I can work on it, although I don't know
> which of the backends I can quickly understand well enough (and test) to
> do this. At least the ps backend looks easy with respect to this change.
> Of course, I would be delighted to see the backend maintainers take this
> on.
>
> Comments?  Alternative proposals?

Darren, John, et al.,

At present it is impossible to render a patch with exactly the 
dimensions specified because a boundary is required.  Present 
workarounds include setting the boundary color to the face color and 
setting a small or zero linewidth.  This is inefficient--a line is being 
rendered when it is not wanted--and imprecise, because the result of a 
very thin or zero-width line depends on the backend and output device.

I propose that the backends be changed so that for any patch-like object 
or collection, setting the boundary linewidth to zero suppresses 
rendering of the line.

I see only advantages and no disadvantages whatsoever to this change; am 
I missing something?

If the proposal meets approval, I can work on it, although I don't know 
which of the backends I can quickly understand well enough (and test) to 
do this. At least the ps backend looks easy with respect to this change. 
Of course, I would be delighted to see the backend maintainers take this on.

Comments?  Alternative proposals?

Eric

Helge,

I have committed some changes to the colorbar positioning code that I 
think fix the bug you found--which was actually a difference between the 
way positioning worked in interactive mode versus in a script--and 
generally improved it.  There is a new kwarg, 'pad', to control the 
spacing.  It is a fraction of the original parent axes.  Defaults are 
0.05 for vertical axes and 0.15 for horizontal; in the latter case, it 
has to leave room for axis tick labels and the x-axis title.  I think 
you will find the defaults tolerable.

The automatic repositioning is crude; it is suitable for interactive 
use, but for production plots people will often need to explicitly size 
and position the primary axes and the colorbar axes.  It can probably be 
improved with a few tweaks here and there, but to do a much better job 
automatically would require major changes, and I don't think this should 
be a high priority. On the other hand, it is possible that redesigning 
positioning and aspect-ratio handling to take full advantage of all the 
wizardry in the transforms code would be a big step forward--but 
probably not an easy one.  I am not going to try it right now.

Thanks again for the clear bug report.

Eric

Helge Avlesen wrote:
> Hi,
> just a small wish for the new colorbar;  I think it by default may be
> positioned a bit too close to the figure,
> see examples below. (plotted by this sequence with yesterdays svn checkout)

Helge,

This is actually a bug in the colorbar positioning that shows up when it 
is put next to a narrow plot.  I will take another look at the 
positioning logic.  Thanks for the report.

Eric

Helge Avlesen wrote:
> Hi,
> just a small wish for the new colorbar;  I think it by default may be
> positioned a bit too close to the figure,
> see examples below. (plotted by this sequence with yesterdays svn checkout)

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I was not aware that my TextWithDash refactor had broken
    Darren> anything. Is this something I should look into?

Basically, mplot3d was using private variables of TextWithDash
(relying on the "has a Text"  rather than "is a Text"
implementation).  So you shouldn't feel bad because your refactor
didn't affect the public API.

You are welcome to look at it, but it's on my list of things to do so
don't feel obligated.

JDH

Looks good, but I think it also needs a 'width' or 'weight' kwarg.
I was also thinking of putting at least a couple of different arrow 
styles in via an 'arrowstyle' kwarg, so I'd pass those through to the 
Arrow LineCollection.

Gary R.

Rob Hetland wrote:
> It might make some sense to rethink the quiver API, especially since it 
> seems there are a few people working toward the same goal (I will help, 
> too, if someone can give me some tasks..).
> 
> Here's a strawman quiver API:
> 
> quiver(x, y, u, v, color='b', scale=1.0, scale_to_grid=False, **kwargs)
> 
>   x, y - quiver should be able to handle *random* (x, y) points (right 
> now, it seems to expect meshed positions -- it seems this is 
> an unnecessary constraint.)
> 
>   color - could be a plot-style color (e.g., 'b', 'k', 'm'), a tuple, or 
> an array the same size as x and y to be mapped using the colormap.
> 
>   scale - is a multiplier for the vector length.
> 
>   scale_to_grid - is a boolean that specifies whether the vectors should 
> be in grid coordinates (True), or scaled to fit nicely (False -- vectors 
> are scaled to fit nice, then multiplied by scale).
> 
>   Plus all the normal kwargs (e.g., cmap). 
> 
> 
> Other potential things to consider include scaling the aspect of the 
> vectors so that the grid can have an aspect ratio unequal to one, but 
> the vectors still scale correctly (i.e., u and v have the same length, 
> even when x is twice y).  
> 
> Finally, I have always wanted an easy way to do curly vectors -- similar 
> to streaklines --  but this might be beyond the scope of the simple 
> quiver command.
> 
> -Rob

I was not aware that my TextWithDash refactor had broken anything. Is this 
something I should look into?

Darren

On Wednesday 24 May 2006 08:58, John Hunter wrote:
> >>>>> "Stefan" == Stefan van der Walt <st...@su...> writes:
>
>     Stefan> But, after fixing all these problems, I still can't get it
>     Stefan> to plot.  It might be worth including surface.py in the
>     Stefan> examples directory, as a test, to guarantee that the 3D
>     Stefan> code gets updated with the rest.
>
>     Stefan> It could be that I am missing something completely obvious
>     Stefan> -- I'd appreciate any help in getting it running!
>
> This code is known to be broken (and never worked).  John Porter's
> code originally worked as an add-on module to matplotlib.  Since then
> TextWithDash has been refactored which broke mplot3d.  I've been
> planning to refactor the code to make it work internally, eg like the
> rest of pylab, but haven't gotten it done yet.
>
> JDH
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
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

Thanks John,
I hope to have another go at this over the weekend but this sounds like 
a promising avenue,
Gary R.

On May 23, 2006, at 2:02 PM, 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.


It might make some sense to rethink the quiver API, especially since  
it seems there are a few people working toward the same goal (I will  
help, too, if someone can give me some tasks..).

Here's a strawman quiver API:

quiver(x, y, u, v, color='b', scale=1.0, scale_to_grid=False, **kwargs)

   x, y - quiver should be able to handle *random* (x, y) points  
(right now, it seems to expect meshed positions -- it seems this is  
an unnecessary constraint.)

   color - could be a plot-style color (e.g., 'b', 'k', 'm'), a  
tuple, or an array the same size as x and y to be mapped using the  
colormap.

   scale - is a multiplier for the vector length.

   scale_to_grid - is a boolean that specifies whether the vectors  
should be in grid coordinates (True), or scaled to fit nicely (False  
-- vectors are scaled to fit nice, then multiplied by scale).

   Plus all the normal kwargs (e.g., cmap).


Other potential things to consider include scaling the aspect of the  
vectors so that the grid can have an aspect ratio unequal to one, but  
the vectors still scale correctly (i.e., u and v have the same  
length, even when x is twice y).

Finally, I have always wanted an easy way to do curly vectors --  
similar to streaklines --  but this might be beyond the scope of the  
simple quiver command.

-Rob

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

>>>>> "Gary" == Gary Ruben <gr...@bi...> writes:

    Gary> I did a tiny bit of work on this over the weekend too and
    Gary> decided to try to use a LineCollection instead of patches
    Gary> inspired by Chris Barker's code, but removing his polar
    Gary> coordinate stuff. Lines seemed a more promising way to go
    Gary> for the arrows, although the width should scale down when
    Gary> the arrows get small so that they're never wider than their
    Gary> length. Using a line collection may not permit this. I also
    Gary> haven't got it working yet. FWIW, Jordan's explanations of
    Gary> expected behaviour have been spot on so far. Also, I'd be
    Gary> happy to see the API fixed up a bit.

You can derive a custom line collection which has this behavior --
LineCollection supports an independent linewidth for each segment, so
as long as you keep an array of linewidths and an array of arrow
lengths, you can clip or set the linelengths at draw time or at
segment setting time.  draw time is probably more appropriate, since
then you can account for figure window size under resizes, etc....

JDH

Hi,
just a small wish for the new colorbar;  I think it by default may be
positioned a bit too close to the figure,
see examples below. (plotted by this sequence with yesterdays svn checkout)

... load data
axis('image')
axis([0,IM,0,JM])
C =3D contourf(x,y,H,levels)
colorbar(C)
hsv()
xlabel('X')
ylabel('Y')
grid(linestyle=3D':')

part of the reason is that I normally use long, outward pointing ticks,
so an extra argument to colorbar to in some way adjust the position
relative to the figure would be useful. Otherwise the new colorbar
works very well!

thanks,
Helge

I did a tiny bit of work on this over the weekend too and decided to try 
to use a LineCollection instead of patches inspired by Chris Barker's 
code, but removing his polar coordinate stuff. Lines seemed a more 
promising way to go for the arrows, although the width should scale down 
when the arrows get small so that they're never wider than their length. 
Using a line collection may not permit this. I also haven't got it 
working yet. FWIW, Jordan's explanations of expected behaviour have been 
spot on so far. Also, I'd be happy to see the API fixed up a bit.

Gary R.

Jordan Dawe wrote:
> 
>> 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

> 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