matplotlib-users Mailing List for matplotlib

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Maybe, but I am not sure it is so simple as that. At the
 Eric> very least, it illustrates the fact that all the possible
 Eric> combinations of rgb with separate alpha, rgba, faces, edges
 Eric> etc. is confusing, and that because of the organic growth of
Yes, this is the result of code creep. Early versions of matplotlib
(GTK only backend) only supported rgb. Later we added an alpha
channel and put it in the graphics context and left the rgb tuples
alone. Later still IIRC we added support rgba colors, while leaving
the alpha in the gc. Thus we have a redundant and somewhat ill
defined alpha. The older drawing methods (draw_line, draw_poly) get
their color as rgb and their alpha from gc. The comparatively newer
ones (draw_poly_collection) always uses the rgba and ignore the
gc.alpha. Definitely confusing, suboptimal, and in need of
rationalization.
 Eric> mpl combined with its support for backends with differing
 Eric> capabilities, there is not a single clear pattern of
 Eric> behavior. Which means we have more cleanup work to do at the
 Eric> very least. To be more ambitious (as if there weren't
 Eric> already enough pending grand ideas), some reconsideration
 Eric> and possible modification of the drawing model would be
 Eric> nice.
Indeed, lots of grand ideas. I've been toying with the idea of trying
to organize an mpl sprint in some fabulous destination, and trying to
raise funds for several developers via donations. Sometime in the
early summer perhaps.
 Eric> For the backends, maybe it would be easier to let (-1,*,*,*)
 Eric> mean "don't draw"; if it has to be interpreted by C-code in
 Eric> some backends, always having a tuple and simply checking for
 Eric> a negative first element is much easier than having to check
 Eric> for None in place of a tuple.
If we are already passing in rgba, and are expecting the backends to
inspect it, wouldn't it make more sense for them to simply check for
rgba[-1]>0, as we do in backend_bases?
JDH

Anyone? :(
-------- Message original --------
Sujet: 3D surface: Updating data?
Date: 2006年12月21日 11:28:43 -0500
De: Nicolas Bigaouette <big...@em...>
Pour: mat...@li...
Hi,
I've been using matplotlib for 2D graphing since two years. Data (3D
array) is created with a Fortran program and ploted using imshow() at a
particular plane.
3D data is created at each time iteration and saved in a file. For the
plotting part, a first imshow() is called with zero values to create the
graph and some text is displayed to describe the graph. Then the python
script read the 3D data and update the graphic using set_data(). That
way, only the "background" image is updated and not the entire graph,
resulting in a faster drawing. At each iteration, a png is saved, giving
the possibility to create a movie of the time evolution.
I would like now to replace the 2D imshow() with the 3D surface_plot().
Saddly, I cannot find a 3D equivalent to set_data(). I get the following
error :
> Traceback (most recent call last):
> File "./src/affichage/affichage_3DE.py", line 450, in updatefig
> im_ez.set_data(Z)
> File "/usr/lib/python2.4/site-packages/matplotlib/art3d.py", line 47, in __getattr__
> return getattr(self.__dict__['_wrapped'], k)
> AttributeError: PolyCollection instance has no attribute 'set_data'
So my question is:
Is there a equivalent of set_data() for surface_plot()?
Thank you very much.
Nicolas

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
> 
> Eric> Try scatter(x, y, alpha=0)
> 
> Hmm, this surprises me -- the edgecolor should respect alpha too, no?
> I'm inclined to consider this a bug -- agree?
Maybe, but I am not sure it is so simple as that. At the very least, it 
illustrates the fact that all the possible combinations of rgb with 
separate alpha, rgba, faces, edges etc. is confusing, and that because 
of the organic growth of mpl combined with its support for backends with 
differing capabilities, there is not a single clear pattern of behavior. 
 Which means we have more cleanup work to do at the very least. To be 
more ambitious (as if there weren't already enough pending grand ideas), 
some reconsideration and possible modification of the drawing model 
would be nice.
> 
> The following should work in any backend that supports alpha
> 
> scatter(rand(100), rand(100), s=50, facecolor=(1,1,1,0))
> 
> Though in older versions of mpl you will need to use a sequence of
> facecolors since earlier versions of collections required all
> properties to be sequences
> 
> scatter(rand(100), rand(100), s=50, facecolor=((1,1,1,0),))
> 
> The problem with alpha solution is it won't work in postscript. We
As you found out, using alpha=0 will work with postscript because it 
gets intercepted and turned into a "don't draw" before it hits the ps 
backend. I think I added this some time ago, probably when we had the 
last round of correspondence about this topic.
> should either adopt the nocolor approach or add the 'fill' property
> like we have in patches. One solution is to modify the color
> converter to return None if the color is 'nocolor' which will allow us
> to continue using None for 'use the default'. The downside is
> modifying all the backends to respect it....
Regardless of any grander schemes, I think something like this (color 
converter modification) is worth doing and not too hard--not terribly 
different from what we already have--so I will look into it more 
closely. The color converter is already a bit complicated, partly 
because of legacy support for float-as-gray, which has been deprecated 
for quite a while now (in favor of 'float'-as-gray). If I add in 
'nocolor' I would want to yank float-as-gray at the same time.
For the backends, maybe it would be easier to let (-1,*,*,*) mean "don't 
draw"; if it has to be interpreted by C-code in some backends, always 
having a tuple and simply checking for a negative first element is much 
easier than having to check for None in place of a tuple.
Eric
> 
> JDH
> 

John Hunter wrote:
>>>>>> "John" == John Hunter <jdh...@ac...> writes:
> 
> John> The problem with alpha solution is it won't work in
> John> postscript. 
> 
> Oh, I see we've already handled this; the
> backend_bases.Renderer.draw_poly_collection catches alpha=0. and sets
> rgbFace to None in this case, so the posted solution works for PS
> backend too.
You're too fast for me. I was just about to send a message pointing 
that out...
Eric
> 
> JDH

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> The problem with alpha solution is it won't work in
 John> postscript. 
Oh, I see we've already handled this; the
backend_bases.Renderer.draw_poly_collection catches alpha=0. and sets
rgbFace to None in this case, so the posted solution works for PS
backend too.
JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Try scatter(x, y, alpha=0)
Hmm, this surprises me -- the edgecolor should respect alpha too, no?
I'm inclined to consider this a bug -- agree?
The following should work in any backend that supports alpha
 scatter(rand(100), rand(100), s=50, facecolor=(1,1,1,0))
Though in older versions of mpl you will need to use a sequence of
facecolors since earlier versions of collections required all
properties to be sequences
 scatter(rand(100), rand(100), s=50, facecolor=((1,1,1,0),))
The problem with alpha solution is it won't work in postscript. We
should either adopt the nocolor approach or add the 'fill' property
like we have in patches. One solution is to modify the color
converter to return None if the color is 'nocolor' which will allow us
to continue using None for 'use the default'. The downside is
modifying all the backends to respect it....
JDH

Try
scatter(x, y, alpha=0)
This works for me with GTKAgg and svn, and I expect it will work with 
87.7 also.
There was some discussion about how to support something like "c=None", 
but I don't recall the outcome, and I don't know whether scatter is now 
an anomaly--but I don't think so. I think we just never got around to 
implementing a uniform solution. (The idea was that we don't want to 
use None in the kwarg to mean no color because it is more useful and 
conventional to have it mean "use the default". Therefore some string 
(e.g. "blank" or "nocolor" or "empty") should be used to denote "don't 
paint it at all", and should always work that way when a colorspec is 
allowed.)
Eric
Yannick Copin wrote:
> Hi,
> 
> I'd like to plot 'open symbols' (i.e. not color filled) w/ scatter. 
> Unfortunately, scatter doesn't support None color:
> 
> scatter(randn(5),randn(5), s=(50,), c=None, edgecolor='r')
> 
> or
> 
> scatter(randn(5),randn(5), s=(50,), facecolor=None, edgecolor='r')
> 
> fail w/
> 
> ValueError: to_rgb: Invalid rgb arg "None"
> 
> Any hint on how to do it? Could None color be supported by scatter, or 
> should I set the markersize of each symbol from a plot command individually?
> 
> Cheers.
> 
> PS: this is a similar question as 
> http://sourceforge.net/mailarchive/message.php?msg_id=11876753, but 
> there was no answer it seems...

Sven Schreiber wrote:
> belinda thom schrieb:
>> Also, since numpy borrows from matlab,
not really -- pylab is specifically designed to be similar to matlab, 
numpy is not -- and the matlib is left over from Numeric, and I don't 
think it was all that well maintained there, either.
> Maybe you know that already, but in scipy there is something like
> scipy.io.read_array and write_array which is very similiar to mpl's
> load/save (IIRC).
> 
> IMHO something like that would be a welcome addition to numpy, but I
> have learned that adding features to numpy is quite controversial...
> (oh, we're on the mpl list right now, ok)
It's an obvious thing to have in a comprehensive package -- maybe not so 
much in numpy. numpy does have the core tools to build that sort of 
thing, however.
> In the end I wrote my own csv read and write functions (see post in
> other thread), because I didn't see why my code should depend on having
> scipy or mpl installed just because of 20 or 30 lines of code.
Again, that is another example of why SciPy should be better modularized 
-- what if it just depended on having scipy.io installed?
> (AFAIK numpy fromfile and tofile are for binary data, not text files.
> Don't know if you want that.)
As mentioned, fromfile and tofile do basic text file support -- but not 
preserving the shape of the array. However, what it does provide is very 
good performance for reading/writing lots of numbers to/from text files 
-- they are great tools for building your own text file 
parser/generator. In fact, your csv reader/writer and much of scipy.io 
could probably benefit from using them (I don't think it does now, as 
the text file support is new to numpy).
I don't know if someone has written it yet, but a load/save pair that 
put a small header with type and shape info in a file, then dumped the 
contents with tofile(...sep=something) could be pretty handy, and fast.
> So if you never use numpy standalone, I'd say go for mpl's load/save.
What about pickle? I'm pretty sure pickle works, doesn't require any 
additional packages, and preserves the format of the array:
import numpy as N
import cPickle
 >>> a = N.arange(24, dtype=N.float)
 >>> a.shape = (2,3,4)
 >>> a
array([[[ 0., 1., 2., 3.],
 [ 4., 5., 6., 7.],
 [ 8., 9., 10., 11.]],
 [[ 12., 13., 14., 15.],
 [ 16., 17., 18., 19.],
 [ 20., 21., 22., 23.]]])
 >>> cPickle.dump(a, file("test.pickle",'wb'))
 >>> b = cPickle.load(file("test.pickle",'rb'))
 >>> b
array([[[ 0., 1., 2., 3.],
 [ 4., 5., 6., 7.],
 [ 8., 9., 10., 11.]],
 [[ 12., 13., 14., 15.],
 [ 16., 17., 18., 19.],
 [ 20., 21., 22., 23.]]])
This is one of those cases where "There should be one obvious way to do 
it" is failing :-(
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I get a lovingly helpful traceback trying to use the histogram function 
that I'm hoping to get some useful help with. The data (and program) 
are at ftp://polar.sri.com/pub/ayoung: hist.dat and hist.py.
Thanks! Andrew
hist.py
--------
from matplotlib import pylab
f = open( 'hist.dat', 'r' )
xs = []
while( True ):
 x = f.readline()
 if x == "": break
 xs.append( float(x) )
xs.sort()
pylab.hist( xs,100 )
[ayoung:ayoung@ayoung-dt ~]$ python hist.py
Warning: invalid value encountered in multiply
Traceback (most recent call last):
 File "hist.py", line 12, in ?
 pylab.hist( xs,100 )
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 
1859, in hist
 ret = gca().hist(*args, **kwargs)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 4157, 
in hist
 patches = self.bar(bins, n, width=width, bottom=bottom, align=align)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2566, 
in bar
 self.autoscale_view()
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 982, 
in autoscale_view
 XL = self.xaxis.get_major_locator().autoscale()
 File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
847, in autoscale
 return take(self.bin_boundaries(dmin, dmax), [0,-1])
 File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
817, in bin_boundaries
 scale, offset = scale_range(vmin, vmax, nbins)
 File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
788, in scale_range
 ex = divmod(math.log10(meanv), 1)[0]
OverflowError: math range error
Linux polar.sri.com 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 
2006 i686 i686 i386 GNU/Linux
Python 2.4.3 (#1, Jun 13 2006, 16:41:18)
matlab: __version__ = '0.85' __revision__ = '$Revision: 1.83 $'

You have to use set_ylim((0,2)) to set the y limits.
Cheers
 Tommy
On Jan 4, 2007, at 11:09 AM, Berthold H=F6llmann wrote:
> Considering the following script I would Expect a resulting y range of
> (1, 2) but I get (1, 3). Is this a bug or a feature. I'm using python
> 2.5, matplotlib 0.87.7.
>
> from matplotlib.backends.backend_agg import FigureCanvasAgg as =20
> FigureCanvas
> from matplotlib.figure import Figure
> fig =3D Figure()
> canvas =3D FigureCanvas(fig)
> ax =3D fig.add_subplot(111)
> lines =3D (ax.plot([1, 2, 3], [1, 2, 3]),)
> axes =3D fig.get_axes()[0]
> axes.set_xlim((0, 2))
> axes.set_aspect('auto', adjustable=3D'box')
> axes.grid(True)
> canvas.print_figure('out.eps')
>
> Kind regards
> Berthold
> --=20
> __ Address:
> G / \ L Germanischer Lloyd
> phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
> fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
>
>
> ----------------------------------------------------------------------=20=
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Considering the following script I would Expect a resulting y range of
(1, 2) but I get (1, 3). Is this a bug or a feature. I'm using python
2.5, matplotlib 0.87.7.
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(111)
lines = (ax.plot([1, 2, 3], [1, 2, 3]),)
axes = fig.get_axes()[0]
axes.set_xlim((0, 2))
axes.set_aspect('auto', adjustable='box')
axes.grid(True)
canvas.print_figure('out.eps')
Kind regards
Berthold
-- 
 __ Address:
 G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg

Nils Wagner wrote:
> Hi,
>
> I have tried to install matplotlib on a x86_64 machine
> using openSUSE10.2.
>
> python setup.py yields
>
> Package pygtk-2.0 was not found in the pkg-config search 
> path.
> Perhaps you should add the directory containing 
> `pygtk-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
>
> echo $PKG_CONFIG_PATH
> /opt/gnome/lib64/pkgconfig
>
> ls -l /opt/gnome/lib64/pkgconfig
> insgesamt 208
> -rw-r--r-- 1 root root 244 27. Nov 22:57 atkmm-1.6.pc
> -rw-r--r-- 1 root root 259 27. Nov 19:36 atk.pc
> -rw-r--r-- 1 root root 419 25. Nov 15:58 
> bonobo-activation-2.0.pc
> -rw-r--r-- 1 root root 243 27. Nov 22:27 cairomm-1.0.pc
> -rw-r--r-- 1 root root 276 27. Nov 22:24 gconf-2.0.pc
> -rw-r--r-- 1 root root 264 28. Nov 03:37 gdict-1.0.pc
> -rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-2.0.pc
> -rw-r--r-- 1 root root 321 27. Nov 22:57 gdkmm-2.4.pc
> -rw-r--r-- 1 root root 262 27. Nov 19:44 gdk.pc
> -rw-r--r-- 1 root root 283 27. Nov 22:05 gdk-pixbuf-2.0.pc
> -rw-r--r-- 1 root root 296 27. Nov 22:04 
> gdk-pixbuf-xlib-2.0.pc
> -rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-x11-2.0.pc
> -rw-r--r-- 1 root root 406 28. Nov 03:44 gimp-2.0.pc
> -rw-r--r-- 1 root root 270 28. Nov 03:44 gimpthumb-2.0.pc
> -rw-r--r-- 1 root root 284 28. Nov 03:44 gimpui-2.0.pc
> -rw-r--r-- 1 root root 334 25. Nov 14:32 glib-2.0.pc
> -rw-r--r-- 1 root root 287 27. Nov 22:30 glibmm-2.4.pc
> -rw-r--r-- 1 root root 237 25. Nov 12:54 glib.pc
> -rw-r--r-- 1 root root 277 25. Nov 14:32 gmodule-2.0.pc
> -rw-r--r-- 1 root root 277 25. Nov 14:32 
> gmodule-export-2.0.pc
> -rw-r--r-- 1 root root 256 25. Nov 14:32 
> gmodule-no-export-2.0.pc
> -rw-r--r-- 1 root root 234 25. Nov 12:54 gmodule.pc
> -rw-r--r-- 1 root root 181 28. Nov 03:46 gnome-mount.pc
> -rw-r--r-- 1 root root 349 28. Nov 00:22 gnome-vfs-2.0.pc
> -rw-r--r-- 1 root root 403 28. Nov 00:22 
> gnome-vfs-module-2.0.pc
> -rw-r--r-- 1 root root 244 25. Nov 14:32 gobject-2.0.pc
> -rw-r--r-- 1 root root 239 25. Nov 14:32 gthread-2.0.pc
> -rw-r--r-- 1 root root 236 25. Nov 12:54 gthread.pc
> -rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-2.0.pc
> -rw-r--r-- 1 root root 180 27. Nov 23:09 gtk-engines-2.pc
> -rw-r--r-- 1 root root 312 27. Nov 22:58 gtkmm-2.4.pc
> -rw-r--r-- 1 root root 195 27. Nov 19:44 gtk+.pc
> -rw-r--r-- 1 root root 318 27. Nov 22:05 
> gtk+-unix-print-2.0.pc
> -rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-x11-2.0.pc
> -rw-r--r-- 1 root root 239 27. Nov 22:09 imlibgdk.pc
> -rw-r--r-- 1 root root 356 27. Nov 22:09 imlib.pc
> -rw-r--r-- 1 root root 414 25. Nov 15:58 libbonobo-2.0.pc
> -rw-r--r-- 1 root root 333 28. Nov 00:49 libgnome-2.0.pc
> -rw-r--r-- 1 root root 236 25. Nov 15:20 libIDL-2.0.pc
> -rw-r--r-- 1 root root 310 27. Nov 23:13 
> libmetacity-private.pc
> -rw-r--r-- 1 root root 358 25. Nov 15:32 ORBit-2.0.pc
> -rw-r--r-- 1 root root 304 25. Nov 15:32 
> ORBit-CosNaming-2.0.pc
> -rw-r--r-- 1 root root 308 25. Nov 15:31 ORBit-idl-2.0.pc
> -rw-r--r-- 1 root root 305 25. Nov 15:32 
> ORBit-imodule-2.0.pc
> -rw-r--r-- 1 root root 268 27. Nov 21:44 pangocairo.pc
> -rw-r--r-- 1 root root 289 27. Nov 21:44 pangoft2.pc
> -rw-r--r-- 1 root root 265 27. Nov 22:57 pangomm-1.4.pc
> -rw-r--r-- 1 root root 314 27. Nov 21:44 pango.pc
> -rw-r--r-- 1 root root 286 27. Nov 21:44 pangoxft.pc
> -rw-r--r-- 1 root root 260 27. Nov 21:44 pangox.pc
> -rw-r--r-- 1 root root 280 25. Nov 13:00 sigc++-2.0.pc
> -rw-r--r-- 1 root root 355 26. Nov 03:28 totem-plparser.pc
>
>
> but locate pygtk-2.0.pc returns nothing.
>
> How can I resolve this problem ?
>
> Nils
>
> 
Nils: Install the package that has pygtk-2.0.pc in it. 
(python-gtk-devel perhaps?).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Hi,
I have tried to install matplotlib on a x86_64 machine
using openSUSE10.2.
python setup.py yields
Package pygtk-2.0 was not found in the pkg-config search=20
path.
Perhaps you should add the directory containing=20
`pygtk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
echo $PKG_CONFIG_PATH
/opt/gnome/lib64/pkgconfig
ls -l /opt/gnome/lib64/pkgconfig
insgesamt 208
-rw-r--r-- 1 root root 244 27. Nov 22:57 atkmm-1.6.pc
-rw-r--r-- 1 root root 259 27. Nov 19:36 atk.pc
-rw-r--r-- 1 root root 419 25. Nov 15:58=20
bonobo-activation-2.0.pc
-rw-r--r-- 1 root root 243 27. Nov 22:27 cairomm-1.0.pc
-rw-r--r-- 1 root root 276 27. Nov 22:24 gconf-2.0.pc
-rw-r--r-- 1 root root 264 28. Nov 03:37 gdict-1.0.pc
-rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-2.0.pc
-rw-r--r-- 1 root root 321 27. Nov 22:57 gdkmm-2.4.pc
-rw-r--r-- 1 root root 262 27. Nov 19:44 gdk.pc
-rw-r--r-- 1 root root 283 27. Nov 22:05 gdk-pixbuf-2.0.pc
-rw-r--r-- 1 root root 296 27. Nov 22:04=20
gdk-pixbuf-xlib-2.0.pc
-rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-x11-2.0.pc
-rw-r--r-- 1 root root 406 28. Nov 03:44 gimp-2.0.pc
-rw-r--r-- 1 root root 270 28. Nov 03:44 gimpthumb-2.0.pc
-rw-r--r-- 1 root root 284 28. Nov 03:44 gimpui-2.0.pc
-rw-r--r-- 1 root root 334 25. Nov 14:32 glib-2.0.pc
-rw-r--r-- 1 root root 287 27. Nov 22:30 glibmm-2.4.pc
-rw-r--r-- 1 root root 237 25. Nov 12:54 glib.pc
-rw-r--r-- 1 root root 277 25. Nov 14:32 gmodule-2.0.pc
-rw-r--r-- 1 root root 277 25. Nov 14:32=20
gmodule-export-2.0.pc
-rw-r--r-- 1 root root 256 25. Nov 14:32=20
gmodule-no-export-2.0.pc
-rw-r--r-- 1 root root 234 25. Nov 12:54 gmodule.pc
-rw-r--r-- 1 root root 181 28. Nov 03:46 gnome-mount.pc
-rw-r--r-- 1 root root 349 28. Nov 00:22 gnome-vfs-2.0.pc
-rw-r--r-- 1 root root 403 28. Nov 00:22=20
gnome-vfs-module-2.0.pc
-rw-r--r-- 1 root root 244 25. Nov 14:32 gobject-2.0.pc
-rw-r--r-- 1 root root 239 25. Nov 14:32 gthread-2.0.pc
-rw-r--r-- 1 root root 236 25. Nov 12:54 gthread.pc
-rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-2.0.pc
-rw-r--r-- 1 root root 180 27. Nov 23:09 gtk-engines-2.pc
-rw-r--r-- 1 root root 312 27. Nov 22:58 gtkmm-2.4.pc
-rw-r--r-- 1 root root 195 27. Nov 19:44 gtk+.pc
-rw-r--r-- 1 root root 318 27. Nov 22:05=20
gtk+-unix-print-2.0.pc
-rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-x11-2.0.pc
-rw-r--r-- 1 root root 239 27. Nov 22:09 imlibgdk.pc
-rw-r--r-- 1 root root 356 27. Nov 22:09 imlib.pc
-rw-r--r-- 1 root root 414 25. Nov 15:58 libbonobo-2.0.pc
-rw-r--r-- 1 root root 333 28. Nov 00:49 libgnome-2.0.pc
-rw-r--r-- 1 root root 236 25. Nov 15:20 libIDL-2.0.pc
-rw-r--r-- 1 root root 310 27. Nov 23:13=20
libmetacity-private.pc
-rw-r--r-- 1 root root 358 25. Nov 15:32 ORBit-2.0.pc
-rw-r--r-- 1 root root 304 25. Nov 15:32=20
ORBit-CosNaming-2.0.pc
-rw-r--r-- 1 root root 308 25. Nov 15:31 ORBit-idl-2.0.pc
-rw-r--r-- 1 root root 305 25. Nov 15:32=20
ORBit-imodule-2.0.pc
-rw-r--r-- 1 root root 268 27. Nov 21:44 pangocairo.pc
-rw-r--r-- 1 root root 289 27. Nov 21:44 pangoft2.pc
-rw-r--r-- 1 root root 265 27. Nov 22:57 pangomm-1.4.pc
-rw-r--r-- 1 root root 314 27. Nov 21:44 pango.pc
-rw-r--r-- 1 root root 286 27. Nov 21:44 pangoxft.pc
-rw-r--r-- 1 root root 260 27. Nov 21:44 pangox.pc
-rw-r--r-- 1 root root 280 25. Nov 13:00 sigc++-2.0.pc
-rw-r--r-- 1 root root 355 26. Nov 03:28 totem-plparser.pc
but locate pygtk-2.0.pc returns nothing.
How can I resolve this problem ?
Nils

On Thursday 04 January 2007 06:13, Sven Schreiber wrote:
> belinda thom schrieb:
> > A tangential question; recently I was looking for a way to save/load
> > numeric data (often so it could be used later for building plots). I
> > found load/save better documented than numpy's to/fromfile, so used
> > that. The question, from the responsibility point of view, however,
> > is where I should be going to get this functionality. Are both
> > equally "stable"? Also, since numpy borrows from matlab, I was
> > surprised that load/save is only provided via matplotlib's mlab.py
> > (its not in numpy's matlib.py).
>
> Maybe you know that already, but in scipy there is something like
> scipy.io.read_array and write_array which is very similiar to mpl's
> load/save (IIRC).
>
> IMHO something like that would be a welcome addition to numpy, but I
> have learned that adding features to numpy is quite controversial...
> (oh, we're on the mpl list right now, ok)
>
> In the end I wrote my own csv read and write functions (see post in
> other thread), because I didn't see why my code should depend on having
> scipy or mpl installed just because of 20 or 30 lines of code.
>
> (AFAIK numpy fromfile and tofile are for binary data, not text files.
> Don't know if you want that.)
You can use numpy's tofile and fromfile for text files, you just have to add a 
delimiter kwarg. However, fromfile only returns 1D arrays.

belinda thom schrieb:
> A tangential question; recently I was looking for a way to save/load 
> numeric data (often so it could be used later for building plots). I 
> found load/save better documented than numpy's to/fromfile, so used 
> that. The question, from the responsibility point of view, however, 
> is where I should be going to get this functionality. Are both 
> equally "stable"? Also, since numpy borrows from matlab, I was 
> surprised that load/save is only provided via matplotlib's mlab.py 
> (its not in numpy's matlib.py).
> 
Maybe you know that already, but in scipy there is something like
scipy.io.read_array and write_array which is very similiar to mpl's
load/save (IIRC).
IMHO something like that would be a welcome addition to numpy, but I
have learned that adding features to numpy is quite controversial...
(oh, we're on the mpl list right now, ok)
In the end I wrote my own csv read and write functions (see post in
other thread), because I didn't see why my code should depend on having
scipy or mpl installed just because of 20 or 30 lines of code.
(AFAIK numpy fromfile and tofile are for binary data, not text files.
Don't know if you want that.)
So if you never use numpy standalone, I'd say go for mpl's load/save.
cheers,
sven

Eric -
Yeah, I agree. The words 'equal' is confusing. But it was taken from matlab.
'scaled' was my invention/doing. I thought it was better than 'equal', as it
makes the scales equal on both axes. Either way, I would like it if we can
fix the data limits in a simple way, and I think incorporating it in
'scaled' would be one option. A new option would be a good idea too.
Something like 'scaledfixed' ? Maybe too long. Or just 'scaledf' ? Code is
simple:
 elif s == 'scaledf':
 self.set_aspect('equal', adjustable='box', anchor='C')
 self.set_autoscale_on(False)
Thanks,
Mark
On 1/3/07, Eric Firing <ef...@ha...> wrote:
>
> Mark Bakker wrote:
> > The enhanced way of handling aspect ratios that Eric implemented works
> > great.
> > There is, however, one change from the old implementation that I don't
> like.
> >
> > In the old implementation, when setting axis('scaled') it also turned
> > autoscale off.
> > This makes sense (and I used it a lot). It means that you can set the
> > axis('scaled'), which means the aspect ratios are set equal and the axis
> > limits are not changed, at any point when you like the data limits. The
> > axis limits are then fixed so that every time you add something else to
> > the figure it will keep these limits.
> >
> > In the new implementation (ok, it has been there for a little while
> > now), you have to give a separate set_autoscale_on(False) command.
> > Besides the odd name of the function (you actually turn the autoscale
> > off), it is a command that should be set right away by axis('scaled').
> > If you want the autoscale to remain on, you should use axis('equal')
>
> Here is the present code fragment (slightly mangled by the mailer):
>
> elif s in ('equal', 'tight', 'scaled', 'normal', 'auto',
> 'image'):
> self.set_autoscale_on(True)
> self.set_aspect('auto')
> self.autoscale_view()
> self.apply_aspect()
> if s=='equal':
> self.set_aspect('equal', adjustable='datalim')
> elif s == 'scaled':
> self.set_aspect('equal', adjustable='box',
> anchor='C')
> elif s=='tight':
> self.autoscale_view(tight=True)
> self.set_autoscale_on(False)
> elif s == 'image':
> self.autoscale_view(tight=True)
> self.set_autoscale_on(False)
> self.set_aspect('equal', adjustable='box',
> anchor='C')
>
> At present, the difference between "equal" and "scaled" is not the
> autoscale state but the "adjustable".
>
> I don't have any objection to changing the behavior of "scaled" as you
> suggest, if that is what people want. Alternatively, yet another word
> could be used to define the behavior you want, and that behavior could
> be added. I don't find "scaled" or "equal" very descriptive or
> intuitive; nor do I find that either word suggests how autoscale should
> be set. (And I agree, "set_autoscale_on(False)" is ugly.)
>
> Eric
>

Fernando Perez wrote:
> hopefully the responsibilities will be:
>
> - ipython -> interactive work
> - numpy/scipy -> numerics
> - matploblib -> plotting
>
On Jan 3, 2007, at 10:01 AM, Christopher Barker wrote:
I sure hope so too.
> Following these ideas, in my personal use I normally do:
>
> import numpy as N
> import scipy as S
> import pylab as P
> At this point, it isn't quite possible to use just matplotlib for
> interactive use, as pylab has the functionality to manage the figure
> windows, etc, so I do use a tiny bit of pylab there, but try to 
> keep to
> the OO interface otherwise.
A tangential question; recently I was looking for a way to save/load 
numeric data (often so it could be used later for building plots). I 
found load/save better documented than numpy's to/fromfile, so used 
that. The question, from the responsibility point of view, however, 
is where I should be going to get this functionality. Are both 
equally "stable"? Also, since numpy borrows from matlab, I was 
surprised that load/save is only provided via matplotlib's mlab.py 
(its not in numpy's matlib.py).
> THe key stumbling block is docs -- most of the docs and tutorials use
> the pylab interface, so it's a bit harder to figure out what to do. 
> This
> should help get you started:
Agreed.
> http://sourceforge.net/mailarchive/message.php?msg_id=11033442
I never found that on the wiki, and have spent some time looking thru 
it.
> (Did that ever get up on the Wiki?, and/or does anyone have other 
> pointers?)
As an experienced Matlab programmer, I have found
http://37mm.no/mpy/matlab-numpy.html
quite useful, but this isn't emphasizing the OO aspect of matplotlib.
>
> -Chris