matplotlib-devel Mailing List for matplotlib

On 6/9/06, Eric Firing <ef...@ha...> wrote:
> Suggestions for improvements in the API or other aspects are welcome.
Hi,
an option for quiver to quickly draw thousands of simple monocolor
arrows each constructed from e.g. 3 line segments would be useful for
someone(like me) that uses matplotlib
for browsing vector plots of large fields (e.g. 800x600). currently
this is not practical
with any of the quiver variants, as it takes minutes to render. I
already use linecollections
to draw high res coastlines, so a faster quiver should be feasible.
another optimization could be perhaps be to arrange for numpy arrays
to be passed directly to the drawing methods instead of the all the
zipping and loops that currently are necessary?
otherwise, quiver2 looks very good for final plots - good work!
Helge

They look great! I would think a DeprecationWarning when you detect
the old usage would suffice for 1 major release cycle, hence all of
0.88.
Thanks,
 Charlie
On 6/9/06, Eric Firing <ef...@ha...> wrote:
> A reimplementation of the quiver command has been committed to svn. It
> is temporarily accessible as "quiver2" so as not to interfere with the
> original quiver, and in examples there is a quiver2_demo.py. The API
> differs from that of the original quiver. See the docstring for
> details. Since the earlier version that I sent out as a diff, I have
> removed the "C" kwarg (unnecessary, given the function signature) and
> added the "minlength" kwarg; if the rendered arrow is less than this
> length in units of the shaft width, then it is replaced with a hexagon
> of this diameter. Also, the dpi bug that John found is fixed.
>
> Some time before the next release I would like to replace the present
> quiver with quiver2. If necessary I can use the same trick as for
> colorbar, in which the default is the new version, but the presence of a
> kwarg exclusive to the old version triggers use of the old version with
> a deprecation warning. I would like to be able to establish a schedule
> for actually removing such deprecated code, however.
>
> Suggestions for improvements in the API or other aspects are welcome.
>
> On my todo list are a "key" method to draw a labeled scale arrow, and an
> ellipse-drawing capability.
>
> The "scatter" command is quite similar and, like the proposed
> "ellipses", could take advantage of code presently in the Quiver class,
> so I will consider doing such a consolidation, using a base class or a
> mixin to factor out as much common functionality as possible.
>
> I have looked briefly at basemap. It looks like quiver2 will fit in OK
> with small changes; a bit more work might be needed to support some of
> the scaling options in quiver2. In any case, whenever quiver2 does
> replace quiver I want to make sure that basemap is ready so that the new
> quiver works well with it; for my own work, velocity vectors on maps are
> central.
>
> Eric
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

A reimplementation of the quiver command has been committed to svn. It 
is temporarily accessible as "quiver2" so as not to interfere with the 
original quiver, and in examples there is a quiver2_demo.py. The API 
differs from that of the original quiver. See the docstring for 
details. Since the earlier version that I sent out as a diff, I have 
removed the "C" kwarg (unnecessary, given the function signature) and 
added the "minlength" kwarg; if the rendered arrow is less than this 
length in units of the shaft width, then it is replaced with a hexagon 
of this diameter. Also, the dpi bug that John found is fixed.
Some time before the next release I would like to replace the present 
quiver with quiver2. If necessary I can use the same trick as for 
colorbar, in which the default is the new version, but the presence of a 
kwarg exclusive to the old version triggers use of the old version with 
a deprecation warning. I would like to be able to establish a schedule 
for actually removing such deprecated code, however.
Suggestions for improvements in the API or other aspects are welcome.
On my todo list are a "key" method to draw a labeled scale arrow, and an 
ellipse-drawing capability.
The "scatter" command is quite similar and, like the proposed 
"ellipses", could take advantage of code presently in the Quiver class, 
so I will consider doing such a consolidation, using a base class or a 
mixin to factor out as much common functionality as possible.
I have looked briefly at basemap. It looks like quiver2 will fit in OK 
with small changes; a bit more work might be needed to support some of 
the scaling options in quiver2. In any case, whenever quiver2 does 
replace quiver I want to make sure that basemap is ready so that the new 
quiver works well with it; for my own work, velocity vectors on maps are 
central.
Eric