Re: [Matplotlib-users] Has nxutils been removed from mpl?
Benjamin Root ben.root@... writes: snip Essentially, you make a Path object using the vertices, and then use its contains_point() method. Ben Root OK, but given that contains_point works with a *single* point at a time, I have to call it for all my points which is a bit more cumbersome, or am I missing something? Jorge -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
+ one on this issue. One of the big advantages of the nxutils points in poly is that you could pass it a large numpy array of points and get back a mask. We found this to be significantly faster than using looping through the single point in poly algorithms from packages like shapely. Echoing Jorge's question how would we do this using contains_point(). - dharhas Jorge Scandaliaris jorgesmbox...@yahoo.es 3/8/2012 3:33 AM Benjamin Root ben.root@... writes: snip Essentially, you make a Path object using the vertices, and then use its contains_point() method. Ben Root OK, but given that contains_point works with a *single* point at a time, I have to call it for all my points which is a bit more cumbersome, or am I missing something? Jorge -- 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 -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
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 -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On Thu, Mar 8, 2012 at 10:47 AM, John Hunter jdh2...@gmail.com wrote: 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. +1 Python 3 support is more important and, quite frankly, overdue--especially given how long it's been sitting in the tree. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
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 -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
_path.cpp already has a number of methods that use Numpy arrays (John is mistaken that it doesn't depend on Numpy), so adding another is no problem. It was my understanding that nxutils was an internal usage module and not part of the public API, and therefore could be removed as long as all of the internal references were updated. It doesn't have a '_' prefix, so of course it being private wasn't explicit, but there are number of things in matplotlib that fall into that category. Apparently, I was mistaken and there are a lot of users using it from outside. It shouldn't be a problem to build a compatibility shim -- I'd much rather do that than have multiple functions -- and adding a points_in_poly to _path.cpp should be pretty straightforward. Mike On 03/08/2012 12:16 PM, Benjamin Root wrote: On Thu, Mar 8, 2012 at 10:47 AM, John Hunter jdh2...@gmail.com mailto:jdh2...@gmail.com wrote: On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root ben.r...@ou.edu mailto: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 -- 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 -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On 03/08/2012 07:16 AM, Benjamin Root wrote: On Thu, Mar 8, 2012 at 10:47 AM, John Hunter jdh2...@gmail.com mailto:jdh2...@gmail.com wrote: On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root ben.r...@ou.edu mailto: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. 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? Eric 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 -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On 03/08/2012 12:35 PM, Michael Droettboom wrote: It shouldn't be a problem to build a compatibility shim -- I'd much rather do that than have multiple functions Oops -- hit send too soon. I meant to say I'd much rather do that than have multiple functions that do virtually the same thing Mike Mike On 03/08/2012 12:16 PM, Benjamin Root wrote: On Thu, Mar 8, 2012 at 10:47 AM, John Hunter jdh2...@gmail.com mailto:jdh2...@gmail.com wrote: On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root ben.r...@ou.edu mailto: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 -- 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 -- 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 -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
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.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Thu, Mar 8, 2012 at 10:47 AM, John Hunter jdh2...@gmail.com mailto:jdh2...@gmail.com wrote: On Thu, Mar 8, 2012 at 10:32 AM, Benjamin Root ben.r...@ou.edu mailto: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 -- 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] Has nxutils been removed from mpl?
Hi, I've had an import error with some of my code, specifically with nxutils (I need it for using points_inside_poly). In [1]: import matplotlib.nxutils as nx --- ImportError Traceback (most recent call last) /home/jscandal/ipython-input-1-c56b9729b42e in module() 1 import matplotlib.nxutils as nx ImportError: No module named nxutils I built mpl from trunk and tried also version 1.1 from my distro, but neither seems to have nxutils. I still find the examples in the docs using it, though, so I am confused. Has nxutils been replaced or removed? Thanks Jorge -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On Wed, Mar 7, 2012 at 10:46 AM, Jorge Scandaliaris jorgesmbox...@yahoo.eswrote: Hi, I've had an import error with some of my code, specifically with nxutils (I need it for using points_inside_poly). In [1]: import matplotlib.nxutils as nx --- ImportError Traceback (most recent call last) /home/jscandal/ipython-input-1-c56b9729b42e in module() 1 import matplotlib.nxutils as nx ImportError: No module named nxutils I built mpl from trunk and tried also version 1.1 from my distro, but neither seems to have nxutils. I still find the examples in the docs using it, though, so I am confused. Has nxutils been replaced or removed? Thanks Jorge Last I heard, it was supposed to be deprecated in master (although it was accidentially removed at one point). Indeed, it appears to be missing from the current master. The deprecation process must be followed! Personally, I think such removal is short-sighted (nxutil's functions are much faster than their python counter-parts). However, it was still in v1.1.x. I suspect that when you tested v1.1.x, you were really running the source build. Verify which version you are testing with: import matplotlib print matplotlib.__version__ print matplotlib.__file__ 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On 03/07/2012 11:59 AM, Benjamin Root wrote: On Wed, Mar 7, 2012 at 10:46 AM, Jorge Scandaliaris jorgesmbox...@yahoo.es mailto:jorgesmbox...@yahoo.es wrote: Hi, I've had an import error with some of my code, specifically with nxutils (I need it for using points_inside_poly). In [1]: import matplotlib.nxutils as nx --- ImportError Traceback (most recent call last) /home/jscandal/ipython-input-1-c56b9729b42e in module() 1 import matplotlib.nxutils as nx ImportError: No module named nxutils I built mpl from trunk and tried also version 1.1 from my distro, but neither seems to have nxutils. I still find the examples in the docs using it, though, so I am confused. Has nxutils been replaced or removed? Thanks Jorge Last I heard, it was supposed to be deprecated in master (although it was accidentially removed at one point). Indeed, it appears to be missing from the current master. The deprecation process must be followed! Personally, I think such removal is short-sighted (nxutil's functions are much faster than their python counter-parts). I agree that the deprecation process should have been followed better. However, I'm not sure what you mean by them being faster than their Pyhton counterparts. Both functions in nxutils are replaced by functions in _path.cpp, which are also written in C++ but are more complete and don't have broken corner cases. They may be slightly slower because they have a few more checks and handle Bezier curves, but they are not significantly slower. Mike -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On Wed, Mar 7, 2012 at 12:31 PM, Michael Droettboom md...@stsci.edu wrote: I agree that the deprecation process should have been followed better. However, I'm not sure what you mean by them being faster than their Pyhton counterparts. Both functions in nxutils are replaced by functions in _path.cpp, which are also written in C++ but are more complete and don't have broken corner cases. They may be slightly slower because they have a few more checks and handle Bezier curves, but they are not significantly slower. What about providing a python module nxutils in master (1.2) that has the same signature as the old nxutils extension code, calls the path functionality, and raises a deprecation warning with suggested a suggested code migration? And then remove it for 1.3 JDH -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On 03/07/2012 01:39 PM, John Hunter wrote: On Wed, Mar 7, 2012 at 12:31 PM, Michael Droettboom md...@stsci.edu mailto:md...@stsci.edu wrote: I agree that the deprecation process should have been followed better. However, I'm not sure what you mean by them being faster than their Pyhton counterparts. Both functions in nxutils are replaced by functions in _path.cpp, which are also written in C++ but are more complete and don't have broken corner cases. They may be slightly slower because they have a few more checks and handle Bezier curves, but they are not significantly slower. What about providing a python module nxutils in master (1.2) that has the same signature as the old nxutils extension code, calls the path functionality, and raises a deprecation warning with suggested a suggested code migration? And then remove it for 1.3 Yeah. I think that's a good way out of this. I'll file a bug and self-assign. Mike -- 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
Re: [Matplotlib-users] Has nxutils been removed from mpl?
On Wed, Mar 7, 2012 at 12:44 PM, Michael Droettboom md...@stsci.edu wrote: On 03/07/2012 01:39 PM, John Hunter wrote: On Wed, Mar 7, 2012 at 12:31 PM, Michael Droettboom md...@stsci.eduwrote: I agree that the deprecation process should have been followed better. However, I'm not sure what you mean by them being faster than their Pyhton counterparts. Both functions in nxutils are replaced by functions in _path.cpp, which are also written in C++ but are more complete and don't have broken corner cases. They may be slightly slower because they have a few more checks and handle Bezier curves, but they are not significantly slower. What about providing a python module nxutils in master (1.2) that has the same signature as the old nxutils extension code, calls the path functionality, and raises a deprecation warning with suggested a suggested code migration? And then remove it for 1.3 Yeah. I think that's a good way out of this. I'll file a bug and self-assign. Mike Thanks for that. As for timing, I have no hard numbers. In fact, after some checking, I just realized that my app that has been using nxutils still even though I am on master! Maybe my slowdown was a coincidence with other changes I have made? Everyone should remember to clear out nxutils.so because the build/clean process won't necessarially do it unless you blow away your install dir. 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
