matplotlib-devel Mailing List for matplotlib

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