matplotlib-users Mailing List for matplotlib

On Wed, Mar 7, 2012 at 12:44 PM, Michael Droettboom <md...@st...> wrote:
> On 03/07/2012 01:39 PM, John Hunter wrote:
>
>
>
> On Wed, Mar 7, 2012 at 12:31 PM, Michael Droettboom <md...@st...>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
>
>
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

It would be a nice idea. I'm not sure it's something that would work 
terribly well in vector backends as the images may not scale well. I 
should mention that there is already support to use arbitrary Unicode 
characters or math expressions as markers already, which does work well 
in vector backends.
Mike
On 03/07/2012 01:59 PM, C M wrote:
> I've for now taken a different approach that means I won't need custom 
> markers from images.
>
> But I'm just curious: is there any wish/plans in Matplotlib to add 
> support for this? I think it could do a lot to expand what's possible 
> in terms of the look and feel of plots (even without things drifing 
> into USA Today territory!).
>
> Just my 0ドル.02
>
> Che
>
>
> ------------------------------------------------------------------------------
> 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

On 03/07/2012 04:51 AM, Giovanni Plantageneto wrote:
> Dear all,
> after upgrading to 1.1.0 on my linux machine (from debian-backports), I
> get an error (Can't set Attribute) with code looking like this:
>
> from pylab import figure
> F=figure()
> F.axes=[]
>
> Why is this so? Incidentally, going back to the previous available
> version (0.99.3) solves the problem.
> Cheers.
Figure.axes is now a read-only property to keep people from shooting 
themselves in the foot, or worse. Figure axes are internally tracked 
via a stack (AxesStack instance) rather than being maintained as a 
simple list.
Eric

I've for now taken a different approach that means I won't need custom
markers from images.
But I'm just curious: is there any wish/plans in Matplotlib to add support
for this? I think it could do a lot to expand what's possible in terms of
the look and feel of plots (even without things drifing into USA Today
territory!).
Just my 0ドル.02
Che

On 03/07/2012 01:39 PM, John Hunter wrote:
>
>
> On Wed, Mar 7, 2012 at 12:31 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> 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

On Wed, Mar 7, 2012 at 12:31 PM, Michael Droettboom <md...@st...> 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

On 03/07/2012 11:59 AM, Benjamin Root wrote:
>
>
> On Wed, Mar 7, 2012 at 10:46 AM, Jorge Scandaliaris 
> <jor...@ya... <mailto:jor...@ya...>> 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

On Wed, Mar 7, 2012 at 11:31 AM, Jorge Scandaliaris
<jor...@ya...>wrote:
> Benjamin Root <ben.root@...> writes:
>
> >
> < snip >
> >
> > import matplotlib
> > print matplotlib.__version__
> > print matplotlib.__file__
> >
> > Ben Root
> >
> >
>
> You're right, 1.1 still has nxutils. What are the python counterparts you
> mention, are they in mpl?
>
> Thanks,
>
> Jorge
>
>
Essentially, you make a Path object using the vertices, and then use its
contains_point() method.
Ben Root

Benjamin Root <ben.root@...> writes:
> 
< snip >
>
> import matplotlib
> print matplotlib.__version__
> print matplotlib.__file__
>
> Ben Root
> 
> 
You're right, 1.1 still has nxutils. What are the python counterparts you
mention, are they in mpl?
Thanks,
Jorge

On Wed, Mar 7, 2012 at 10:46 AM, Jorge Scandaliaris
<jor...@ya...>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).
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

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

Dear all,
after upgrading to 1.1.0 on my linux machine (from debian-backports), I get
an error (Can't set Attribute) with code looking like this:
from pylab import figure
F=figure()
F.axes=[]
Why is this so? Incidentally, going back to the previous available version
(0.99.3) solves the problem.
Cheers.

> Perhaps you should post that question for the numpy mailing list?
Thanks, I will try that. I have no clues
Cheers,
Lucia
> On Mon, Mar 5, 2012 at 1:47 PM, <av...@fa...> wrote:
>
>> > On Feb 23, 2012 1:39 PM, <av...@fa...> wrote:
>> >>
>> >> should I reinstall numpy?
>> >
>> > No need. You should be able to build matplotlib without sudo and then
>> > install with sudo
>> >
>> > python setup.py build
>> > sudo python setup.py install
>>
>> Yes! This is how it should be, but it's not.
>>
>> I have gone a litte further trying to solve this. I have found out the
>> following:
>>
>> If I do an import numpy in python run as user, it works. In fact,
>> 'python
>> setup.py build' works perfectly as user. But if I do an import numpy in
>> python run as root, I get the error I pasted in my previous message:
>>
>> :~/matplotlib$ sudo python
>> Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
>> [GCC 4.6.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import numpy
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "/usr/local/lib/python2.7/dist-packages/numpy/__init__.py", line
>> 137, in <module>
>> import add_newdocs
>> File "/usr/local/lib/python2.7/dist-packages/numpy/add_newdocs.py",
>> line
>> 9, in <module>
>> from numpy.lib import add_newdoc
>> File "/usr/local/lib/python2.7/dist-packages/numpy/lib/__init__.py",
>> line 13, in <module>
>> from polynomial import *
>> File "/usr/local/lib/python2.7/dist-packages/numpy/lib/polynomial.py",
>> line 17, in <module>
>> from numpy.linalg import eigvals, lstsq
>> File "/usr/local/lib/python2.7/dist-packages/numpy/linalg/__init__.py",
>> line 48, in <module>
>> from linalg import *
>> File "/usr/local/lib/python2.7/dist-packages/numpy/linalg/linalg.py",
>> line 23, in <module>
>> from numpy.linalg import lapack_lite
>> ImportError: libifport.so.5: cannot open shared object file: No such
>> file
>> or directory
>>
>> After that I thought it must be something about this libifport.so that
>> numpy uses, but...
>>
>> :~/matplotlib$ locate libifport
>> /opt/intel/Compiler/11.1/038/lib/intel64/libifport.a
>> /opt/intel/Compiler/11.1/038/lib/intel64/libifport.so
>> /opt/intel/Compiler/11.1/038/lib/intel64/libifport.so.5
>> :~/matplotlib$
>>
>> :~$ echo $LD_LIBRARY_PATH
>>
>> /opt/intel/Compiler/11.1/038/lib/intel64:/opt/intel/Compiler/11.1/038/mkl/lib/em64t
>> :~$ sudo -s
>> root@:~# echo $LD_LIBRARY_PATH
>>
>> /opt/intel/Compiler/11.1/038/lib/intel64:/opt/intel/Compiler/11.1/038/mkl/lib/em64t
>>
>> So I don't know why python fails to import numpy as root... and I don't
>> know why mpl's installer needs to import numpy to install what has
>> already
>> been built.
>>
>> I haven't been able to solve this issue yet. Thank you all very much for
>> all your help.
>>
>> Cheers,
>> Lucia.
>>
>>
>>
> Part of the build process imports numpy in order to check its version (I
> think). But the bigger question is why it fails as root. That is very
> odd.
>
> Perhaps you should post that question for the numpy mailing list?
>
> Cheers!
> Ben Root
>

Mic:
> Hello,
> I am able to draw a histogram with the following code:
>
> /.../
> /h.hist(hist_data, bins=50, normed=True)/
>
> However, I don't know how to draw a line for median at 249 position 
> like in attachment.
Are your axes really matplotlib axes? (I have doubts, since the vertical 
is not normed, although your histogram is).
In your real axes, the command plot([249,249],[0,height]) draws a 
vertical line (there is a primitive vert. line as well), what is the 
problem??
Jerzy Karczmarczuk