[matplotlib-devel] quiver2 in svn
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] quiver2 in svn
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 <[EMAIL PROTECTED]> 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] quiver2 in svn
On 6/9/06, Eric Firing <[EMAIL PROTECTED]> 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
