On Thu, Mar 8, 2012 at 11:16 AM, Benjamin Root <ben.r...@ou.edu> wrote:
>
>
> On Thu, Mar 8, 2012 at 10:47 AM, John Hunter <jdh2...@gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root <ben.r...@ou.edu> 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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
