+1 as well. I just took another look at the Path object and I
see no such function. The lack of this function is a problem
for me as well in my existing apps. In order to deprecate
nxutils, this functionality needs to be added to Path.
Otherwise, nxutils *must* be reinstated before the next release.
Michael has already agreed to make a nxutils compatibility layer
that would have the same interface as the old nxutils. So we are
talking about performance, not core functionality.
We should remember that Michael did the lion's share of the work on
porting mpl to python 3
elected not to port all of the C++ if he could replace some of the
functionality with the core. So those who rely on bare metal speed
the you are getting in nxutils should step up to either :
1) help with the port of nxutils to python 3
2) help with exposing methods in _path.cpp that are almost as fast
3) live with slower speeds in the compatibility layer he has agreed
4) ask (nicely) for someone to help you
I prefer option 2 because this is fairly easy and avoids code
redundancy. It would take just a few lines of extra code to do this
with the python sequence protocol as inputs and python lists as
return values. It would take a bit more to support numpy arrays as
input and output, and we should get input from Michael about the
desirability of making _path.cpp depend on numpy. I don't see the
harm, but I'd like to verify.
In my opinion, a slower implementation in a
nxutils.py compatibility module is not a release stopper, even if it
Don't get me wrong. If help is needed, I can certainly provide it since
it is my itch. I am just a little exasperated with how this issue has
been handled up to now. The shim is a very good idea and it should have
been done back when the py3k merge happened. I didn't press the issue
then because I was traveling and didn't have time to examine the issue
closely, and having _nxutils.so still in my build hide the problem from
me (my own fault).
As for shim implementation, I would be willing to accept a slightly
slower function now (with the promise of improvements later), but if the
implementation is too much slower, then effort will need to be made to
get it up to acceptable levels. I know of several users **cough**my
future employer**cough** who uses functionality such as this, and they
would not be happy if their products are dragged down by such a bottleneck.
For my own purposes I decided to simply copy the pnpoly core and write a cython wrapper, since nxutils did not seem to have a secure future in mpl. If anyone is interested in this approach, see the files _pnpoly.c
and utility.pyx (last function therein) in the num/src subdirectory of my "pycurrents" repo: http://currents.soest.hawaii.edu/hgstage/pycurrents/shortlog/tip. The wrapper is brand-new and very lightly tested; I suspect it could be improved considerably. (Also, at present it has only the points_in_poly function.)
Probably about time I dug more into CXX wrapped stuff...
mpl strategy question: stick with CXX and hand-wrapping exclusively, or start using cython?
On 03/08/2012 07:16 AM, Benjamin Root wrote:
On Thu, Mar 8, 2012 at 10:47 AM, John Hunter <jdh2358@…287… > <mailto:jdh2358@…287…>> wrote:
On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root <ben.root@…1304… > <mailto:ben.root@…1304…>> wrote:
Virtualization& Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
Matplotlib-users mailing list