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

[Benjamin R. <ben...@ou...>]

On Thu, Mar 8, 2012 at 11:16 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Thu, Mar 8, 2012 at 10:47 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root <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