Re: [Matplotlib-users] Has nxutils been removed from mpl?

[Michael D. <md...@st...>]

There is a proposed solution to all of this here:

https://github.com/matplotlib/matplotlib/pull/746

Please test -- I don't have any nxutils-using code myself, and 
matplotlib itself has none.  We should probably convert some of the 
nxutils code in the wild into some unit tests.

Mike

On 03/08/2012 12:37 PM, Benjamin Root wrote:
>
>
> On Thu, Mar 8, 2012 at 11:16 AM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
>
>
>     On Thu, Mar 8, 2012 at 10:47 AM, John Hunter <jd...@gm...
>     <mailto:jd...@gm...>> wrote:
>
>
>
>         On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root
>         <ben...@ou... <mailto:ben...@ou...>> wrote:
>
>
>             +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
>         (https://github.com/matplotlib/matplotlib/pull/565/commits).
>          He 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 or faster
>
>         3) live with slower speeds in the compatibility layer he has
>         agreed to write
>
>         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 is undesirable.
>
>         JDH
>
>
>     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.
>
>     Probably about time I dug more into CXX wrapped stuff...
>
>     Ben Root
>
>
>
> Looking over the code, it looks like we could generalize 
> point_in_path_impl() into points_in_path_impl().  The current code 
> iterates through the path vertices to test a single point.  Putting 
> this action inside a loop (for each point that we want to test) would 
> mean that this iterator has to be processed each time, which I suspect 
> would kill performance when the number of vertices is far greater than 
> the number of test points.
>
> Tinkering....
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> 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.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users