matplotlib-users Mailing List for matplotlib

Derrick Snowden wrote:
> John Hunter wrote:
>
>>>>>>> "Derrick" == Derrick Snowden <Der...@no...> writes:
>>>>>>> 
>>>>>>
>> Derrick> This brings me to my last question. Has anyone out there
>> Derrick> had any problems with the sourceforge cvs?
>> Or you might ask "has anyone not had problems...." :-)
>>
>> I uploaded a snapshot of my local tree to
>>
>> http://matplotlib.sf.net/matplotlib-0.81alpha.tar.gz
>>
>> JDH
>>
>> 
>>
> Thanks, this seems to have fixed all the problems when using Numeric. 
> The following is the error I get when using numarray...NOTE that the 
> error occurs when I close the plot. The plot is generated on the screen.
>
> [snowden@doris Python]$ python p_hb_example.py --numarray
> loaded rc file /home/snowden/.matplotlibrc
> matplotlib version 0.81alpha
> verbose.level helpful
> interactive is False
> platform is linux2
> numerix numarray 1.3.1
> font search path ['/usr/share/matplotlib']
> loaded ttfcache file /home/snowden/.ttffont.cache
> matplotlib data path /usr/share/matplotlib
> backend GTKAgg version 2.2.0
> /usr/lib/python2.3/site-packages/numarray/numarraycore.py:368: 
> UserWarning: __array__ returned non-NumArray instance
> _warnings.warn("__array__ returned non-NumArray instance")
> Traceback (most recent call last):
> File "p_hb_example.py", line 60, in ?
> pylab.plot(dtnum,v3)
> File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line 
> 1945, in plot
> ret = gca().plot(*args, **kwargs)
> File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 
> 2490, in plot
> for line in self._get_lines(*args, **kwargs):
> File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 272, 
> in _grab_next_args
> yield self._plot_2_args(remaining, **kwargs)
> File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 222, 
> in _plot_2_args
> assert(iterable(y))
> AssertionError
I have a problem after the change made by John to pass to agg23. I have 
to delete the build directory and the matplotlib directory in 
site-package and the cvs version is working fine. In other hand I have a 
segmentation fault when I tried to use mpl.
my 2 cents,
 N.

I am current using Matplotlib in several projects, including a project of 
autonomous rough terrain vehicles, a project predicting California coastal 
winds, and a project that organizes earth science data from several NASA 
satellites. Matplotlib is very flexible and versatile, and has a well 
designed foundation. It is the best graphics package I have used in my 20 
years of research career. John Hunter and his army of volunteers did an 
excellent job developing Matplotlib in such a short time. But the software 
needs to be developed further to expand the capabilities. Money invested on 
developing Matplotlib will be well spent, and eventually will save the 
funding agencies because the scientists will not have to buy the expensive 
commercial softwares like Matlab and IDL.
I have heard several very positive comments on Matplotlib from our JPL Python 
community.
On Wednesday 18 May 2005 10:44 am, John Hunter wrote:
> If you are using python for high performance or scientific computing,
> could I ask you to send me a blurb (one or two sentences) on what you
> are using it for and if you have any publications or references
> related to this work (the refs don't have to be specifically about the
> python stuff) please include them (extra points for bibtex).
>
> I am writing some grant text justifying python in scientific computing
> and would like to have a range of examples across disciplines to
> provide.
>
> If I could get these today or tomorrow that would be very helpful!
> Please send these to me off list.
>
> Thanks!
> JDH
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Benyang Tang, Ph.D.
tel: (818)354-0327, email: benyang.tang _at_ jpl.nasa.gov
Machine Learning Systems Group ---- http://ml.jpl.nasa.gov
M/S 126-347, Jet Propulsion Laboratory
4800 Oak Grove Drive, Pasadena, CA 91109, USA

John Hunter wrote:
>>>>>>"Derrick" == Derrick Snowden <Der...@no...> writes:
>>>>>> 
>>>>>>
> Derrick> This brings me to my last question. Has anyone out there
> Derrick> had any problems with the sourceforge cvs? 
>
>Or you might ask "has anyone not had problems...." :-)
>
>I uploaded a snapshot of my local tree to
>
> http://matplotlib.sf.net/matplotlib-0.81alpha.tar.gz
>
>JDH
>
> 
>
Thanks, this seems to have fixed all the problems when using Numeric. 
The following is the error I get when using numarray...NOTE that the 
error occurs when I close the plot. The plot is generated on the screen.
[snowden@doris Python]$ python p_hb_example.py --numarray
loaded rc file /home/snowden/.matplotlibrc
matplotlib version 0.81alpha
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.3.1
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/snowden/.ttffont.cache
matplotlib data path /usr/share/matplotlib
backend GTKAgg version 2.2.0
/usr/lib/python2.3/site-packages/numarray/numarraycore.py:368: 
UserWarning: __array__ returned non-NumArray instance
 _warnings.warn("__array__ returned non-NumArray instance")
Traceback (most recent call last):
 File "p_hb_example.py", line 60, in ?
 pylab.plot(dtnum,v3)
 File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line 
1945, in plot
 ret = gca().plot(*args, **kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 2490, 
in plot
 for line in self._get_lines(*args, **kwargs):
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 272, 
in _grab_next_args
 yield self._plot_2_args(remaining, **kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 222, 
in _plot_2_args
 assert(iterable(y))
AssertionError

If you are using python for high performance or scientific computing,
could I ask you to send me a blurb (one or two sentences) on what you
are using it for and if you have any publications or references
related to this work (the refs don't have to be specifically about the
python stuff) please include them (extra points for bibtex).
I am writing some grant text justifying python in scientific computing
and would like to have a range of examples across disciplines to
provide. 
If I could get these today or tomorrow that would be very helpful!
Please send these to me off list.
Thanks!
JDH

>>>>> "Derrick" == Derrick Snowden <Der...@no...> writes:
 Derrick> This brings me to my last question. Has anyone out there
 Derrick> had any problems with the sourceforge cvs? 
Or you might ask "has anyone not had problems...." :-)
I uploaded a snapshot of my local tree to
 http://matplotlib.sf.net/matplotlib-0.81alpha.tar.gz
JDH

Here's another vote for ditching from import *. As we get more and more 
experience writing larger python programs, using import * just seems to 
cause more and more problems. Given the huge variety of modules out there, 
it's impossible to avoid name conflicts and it's almost impossible to track 
down conflicts when they occur. We've started 
instructing/pushing/cajoling our users to do exactly what Fernando has 
suggested:
import pylab as P
Ted
At 10:04 AM 5/18/2005, Derrick Snowden wrote:
>Fernando Perez wrote:
>
>>John Hunter wrote:
>>
>>>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes:
>>>
>>> >> I'm wondering if set is now a bad name for pylab to be using?
>>>
>>> Tim> +1 for changing it.
>>>
>>> Tim> I've also had this issue bite me when I was hacking together
>>> Tim> some code and wanted to use a python set. I'd be in favour of
>>> Tim> changing the pylab set to be called something else, although
>>> Tim> I don't have any good suggestions about what to change it
>>> Tim> to...
>>>
>>>Ouch, I hadn't thought of this. In the past, consensus has been that
>>>pylab should not override built-ins, eg the previous discussion on
>>>min/max which led us to rename these functions to amin/amax. Changing
>>>set, unfortunately, will break a lot of scripts. I think the best
>>>plan of action is to define a new function pset or setp (setp for "set
>>>property") which has the functionality of the old, and keep set around
>>>for a release or two issuing a warning with a line number so people
>>>can get their existing scripts cleaned up.
>>
>>
>>I'd also suggest removing from all example code 'from pylab import *' 
>>statements. Frankly, after a while I've completely stopped using 'from 
>>foo import *' in _any_ code I write, even small scripts. All I use these 
>>days is code like:
>>
>>import Numeric as N
>>import scipy as S
>>import pylab as P
>>
>>The only place where I think that from-import-* is OK is at an 
>>interactive prompt, where you are just doing experiments and not writing 
>>reusable code.
>>
>>Since the examples tend to be the place that people learn from, I think 
>>it would be a good idea to encourage safer practices by banning the 
>>dangerous import-* idiom from there.
>>
>>Just my opinion.
>>
>>Best,
>>
>>f
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Matplotlib-users mailing list
>>Mat...@li...
>>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>As the new learner that Fernando alludes to, I'd like to second his 
>opinion. As we speak, I'm looking through examples I've collected trying 
>to piece together something useful for my work. The namespace conflicts 
>are a huge frustration, especially with regard to numarray/Numeric 
>overlap. As a newbie, this is almost a show stopper.
>I'll figure it out eventually I hope...
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Ted Drain Jet Propulsion Laboratory ted...@jp... 

John Hunter wrote:
>>>>>>"Derrick" == Derrick Snowden <Der...@no...> writes:
>>>>>> 
>>>>>>
>
> Derrick> When I plot the data with missing values (say the mask is
> Derrick> 1.0e20) it obviously screws up the range of the y limits.
> Derrick> I've seen other packages which understand a missing_value
> Derrick> attribute or a fill_value attribute and leave that
> Derrick> section of the curve blank. I was hoping for a behavior
> Derrick> similar to Matlab, when the data vector contains NaNs. I
> Derrick> see some mention of this in the matplotlib-devel list
> Derrick> (J. Whitaker's patch for pcolor) and I see a keyword
> Derrick> argument for contourf that seems to address this
> Derrick> situation. Is there anything for line plots?
>
>Eric Firing contributes a patch for masked array support for line
>plots which is in CVS. I haven't tried this with date plots but there
>is every reason to believe it will "just work"
>
>See examples/masked_demo.py in CVS.
>
>Let me know!
>
>JDH
> 
>
Some progress on this front...thanks for all your suggestions. I tried 
to go with John's suggestion as it seems the most complete in the long 
run. I had some success, and some errors. First the success...
After downloading lines.py from cvs and reinstalling, I ran into an 
error trying to run the examples/masked_array.py. The error message 
differed depending on whether I used numarray or numeric. I won't 
include it here because I got past that point by downloading axes.py and 
reinstalling. 
1. When I tried
python masked_array.py --numarray
I got the following error and no plot...
[snowden@doris examples]$ python masked_demo.py --numarray
/usr/lib/python2.3/site-packages/matplotlib/__init__.py:636: 
UserWarning: Bad key "verbose.erro" on line 199 in 
/home/snowden/.matplotlibrc
 warnings.warn('Bad key "%s" on line %d in %s' % (key, cnt, fname))
loaded rc file /home/snowden/.matplotlibrc
matplotlib version 0.80
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.3.1
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/snowden/.ttffont.cache
matplotlib data path /usr/share/matplotlib
backend GTKAgg version 2.2.0
Traceback (most recent call last):
 File "masked_demo.py", line 19, in ?
 lines = plot(x, y, 'r', x, ym1, 'g', x, ym2, 'bo')
 File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line 
1899, in plot
 ret = gca().plot(*args, **kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 2491, 
in plot
 self.add_line(line)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 732, 
in add_line
 self.update_datalim_numerix( xdata, ydata )
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 717, 
in update_datalim_numerix
 self.dataLim.update_numerix(x, y, not self.has_data())
ValueError: x and y must be equal length sequences
2. When I tried
python masked_array.py --Numeric
I get a plot, but while the plot is active an error message is 
periodically scrolling across the terminal screen. (I'm using GTKAgg)
Traceback (most recent call last):
 File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py", 
line 163, in motion_notify_event
 FigureCanvasBase.motion_notify_event(self, x, y)
 File "/usr/lib/python2.3/site-packages/matplotlib/backend_bases.py", 
line 743, in motion_notify_event
 func(event)
 File "/usr/lib/python2.3/site-packages/matplotlib/backend_bases.py", 
line 997, in mouse_move
 s = event.inaxes.format_coord(event.xdata, event.ydata)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 609, 
in format_coord
 xs = self.format_xdata(x)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 591, 
in format_xdata
 func = self.xaxis.get_major_formatter().format_data
AttributeError: ScalarFormatter instance has no attribute 'format_data'
I suppose this is successful in that I get a plot to come on the screen 
but I doubt it's the solution you intended... Any ideas?
This brings me to my last question. Has anyone out there had any 
problems with the sourceforge cvs? I am unable to log in using the 
commands that are suggested on the sourceforege site. I am at a 
government site and am behind a firewall. Before I delve into cvs too 
deeply, I wondered if firewalls are known to not work well with cvs 
servers? I have had some difficulties with rsync servers in the past.
Thanks again,
Derrick

Fernando Perez wrote:
> John Hunter wrote:
>
>>>>>>> "Tim" == Tim Leslie <ti...@cs...> writes:
>>>>>>
>>
>> >> I'm wondering if set is now a bad name for pylab to be using?
>>
>> Tim> +1 for changing it.
>>
>> Tim> I've also had this issue bite me when I was hacking together
>> Tim> some code and wanted to use a python set. I'd be in favour of
>> Tim> changing the pylab set to be called something else, although
>> Tim> I don't have any good suggestions about what to change it
>> Tim> to...
>>
>> Ouch, I hadn't thought of this. In the past, consensus has been that
>> pylab should not override built-ins, eg the previous discussion on
>> min/max which led us to rename these functions to amin/amax. Changing
>> set, unfortunately, will break a lot of scripts. I think the best
>> plan of action is to define a new function pset or setp (setp for "set
>> property") which has the functionality of the old, and keep set around
>> for a release or two issuing a warning with a line number so people
>> can get their existing scripts cleaned up.
>
>
> I'd also suggest removing from all example code 'from pylab import *' 
> statements. Frankly, after a while I've completely stopped using 
> 'from foo import *' in _any_ code I write, even small scripts. All I 
> use these days is code like:
>
> import Numeric as N
> import scipy as S
> import pylab as P
>
> The only place where I think that from-import-* is OK is at an 
> interactive prompt, where you are just doing experiments and not 
> writing reusable code.
>
> Since the examples tend to be the place that people learn from, I 
> think it would be a good idea to encourage safer practices by banning 
> the dangerous import-* idiom from there.
>
> Just my opinion.
>
> Best,
>
> f
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
As the new learner that Fernando alludes to, I'd like to second his 
opinion. As we speak, I'm looking through examples I've collected 
trying to piece together something useful for my work. The namespace 
conflicts are a huge frustration, especially with regard to 
numarray/Numeric overlap. As a newbie, this is almost a show stopper. 
I'll figure it out eventually I hope...

John Hunter wrote:
>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes:
> 
> >> I'm wondering if set is now a bad name for pylab to be using?
> 
> Tim> +1 for changing it.
> 
> Tim> I've also had this issue bite me when I was hacking together
> Tim> some code and wanted to use a python set. I'd be in favour of
> Tim> changing the pylab set to be called something else, although
> Tim> I don't have any good suggestions about what to change it
> Tim> to...
> 
> Ouch, I hadn't thought of this. In the past, consensus has been that
> pylab should not override built-ins, eg the previous discussion on
> min/max which led us to rename these functions to amin/amax. Changing
> set, unfortunately, will break a lot of scripts. I think the best
> plan of action is to define a new function pset or setp (setp for "set
> property") which has the functionality of the old, and keep set around
> for a release or two issuing a warning with a line number so people
> can get their existing scripts cleaned up.
I'd also suggest removing from all example code 'from pylab import *' 
statements. Frankly, after a while I've completely stopped using 'from foo 
import *' in _any_ code I write, even small scripts. All I use these days is 
code like:
import Numeric as N
import scipy as S
import pylab as P
The only place where I think that from-import-* is OK is at an interactive 
prompt, where you are just doing experiments and not writing reusable code.
Since the examples tend to be the place that people learn from, I think it 
would be a good idea to encourage safer practices by banning the dangerous 
import-* idiom from there.
Just my opinion.
Best,
f

On 2005年5月18日, John Hunter <jdh...@ac...> wrote...
> >>>>> "Tim" =3D=3D Tim Leslie <ti...@cs...> writes:
> >> I'm wondering if set is now a bad name for pylab to be using?
>=20
> Tim> +1 for changing it.
>=20
> Tim> I've also had this issue bite me when I was hacking together
> Tim> some code and wanted to use a python set. I'd be in favour of
> Tim> changing the pylab set to be called something else, although
> Tim> I don't have any good suggestions about what to change it
> Tim> to...
>=20
> Ouch, I hadn't thought of this. In the past, consensus has been that
> pylab should not override built-ins, eg the previous discussion on
> min/max which led us to rename these functions to amin/amax. Changing
> set, unfortunately, will break a lot of scripts. I think the best
> plan of action is to define a new function pset or setp (setp for "set
> property") which has the functionality of the old, and keep set around
> for a release or two issuing a warning with a line number so people
> can get their existing scripts cleaned up.
This sounds like a perfectly valid course of action to me. In the
meantime, if people want to have set refer to python sets and setp refer=20
to the pylab set function the following should work (untested):
=66rom pylab import *
setp =3D set
set =3D __builtins__.set
Tim
>=20
> JDH
>=20
`-

>>>>> "Tim" == Tim Leslie <ti...@cs...> writes:
 >> I'm wondering if set is now a bad name for pylab to be using?
 Tim> +1 for changing it.
 Tim> I've also had this issue bite me when I was hacking together
 Tim> some code and wanted to use a python set. I'd be in favour of
 Tim> changing the pylab set to be called something else, although
 Tim> I don't have any good suggestions about what to change it
 Tim> to...
Ouch, I hadn't thought of this. In the past, consensus has been that
pylab should not override built-ins, eg the previous discussion on
min/max which led us to rename these functions to amin/amax. Changing
set, unfortunately, will break a lot of scripts. I think the best
plan of action is to define a new function pset or setp (setp for "set
property") which has the functionality of the old, and keep set around
for a release or two issuing a warning with a line number so people
can get their existing scripts cleaned up.
JDH

On 2005年5月18日, John Gill <jn...@eu...> wrote...
> In python 2.4 set is available as a built-in type.
> 
> Now if I do:
> 
> from pylab import *
> 
> I get a function called set, which I can use to set properties on pylab 
> objects.
> 
> I'm wondering if set is now a bad name for pylab to be using?
+1 for changing it.
I've also had this issue bite me when I was hacking together some code and
wanted to use a python set. I'd be in favour of changing the pylab set to
be called something else, although I don't have any good suggestions about
what to change it to...
Tim
> 
> John
`-

In python 2.4 set is available as a built-in type.
Now if I do:
from pylab import *
I get a function called set, which I can use to set properties on pylab 
objects.
I'm wondering if set is now a bad name for pylab to be using?
John

I'll have a play to see if I can make this a bit smarter.
John
Florian Lindner wrote:
> Am Dienstag, 17. Mai 2005 19:43 schrieb John Hunter:
> > >>>>> "Florian" == Florian Lindner <mai...@xg...> writes:
> >
> > Florian> Hello, how does loc=0 (best) affects the placement of the
> > Florian> legend? I can't really figure out any influence. There is
> > Florian> space (on the upper left) where the legend could be
> > Florian> placed without hiding any lines but it's still placed on
> > Florian> the upper right.
> >
> > If what you say is correct, then it is a bug. Please post a complete
> > example.
>
> It is correct.
>
> But the John Gill gave me a explanation of this behavior which is 
> correct for
> my case. It is not a bug, just a lazy implementation of the feature 
> and he is
> aware of that.
>
> Florian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click 
> <http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>