matplotlib-users Mailing List for matplotlib

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

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')
Anybody else an opinion? Andrea?
Thanks, Mark

Thanks for writing the convenience function John !
I think there is a large group (like the students in my class) who use
matplotlib as a simple tool to make beautiful graphs. To compete with matlab
we need to keep simple tasks simple. I personally think that this
convenience function is a good one to add. Probably under pylab.
Anybody else want to weigh in?
Mark
On 1/3/07, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
> Mark> Thanks John. This works great. I think, however, that
> Mark> set_backgroundcolor would be useful. It should be easy to
> Mark> fix. If nobody speaks up, I will take a crack at it, Mark
>
> What do you have in mind, a simple convenience function that does
>
> def set_backgroundcolor(self, color):
> """
> Set the background color of the text by updating the bbox
> facecolor
>
> ACCEPTS: any matplotlib color
> """
> if self._bbox is None:
> self._bbox = dict(facecolor=color, edgecolor=color)
> else:
> self._bbox.update(dict(facecolor=color))
>
> I'm not too opposed to it, but it does violate the maxim "There should be
> one--
> and preferably only one --obvious way to do it." Of course, we
> violate this throughout mpl offerings lots of convenience functions,
> but it is something to bear in mind.
>

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> Thanks John. This works great. I think, however, that
 Mark> set_backgroundcolor would be useful. It should be easy to
 Mark> fix. If nobody speaks up, I will take a crack at it, Mark
What do you have in mind, a simple convenience function that does
 def set_backgroundcolor(self, color):
 """
 Set the background color of the text by updating the bbox facecolor
 ACCEPTS: any matplotlib color 
 """
 if self._bbox is None: 
 self._bbox = dict(facecolor=color, edgecolor=color)
 else:
 self._bbox.update(dict(facecolor=color))
I'm not too opposed to it, but it does violate the maxim "There should be one--
and preferably only one --obvious way to do it." Of course, we
violate this throughout mpl offerings lots of convenience functions,
but it is something to bear in mind.

Thanks John. This works great.
I think, however, that set_backgroundcolor would be useful.
It should be easy to fix.
If nobody speaks up, I will take a crack at it,
Mark
On 1/3/07, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
> Mark> Hello - I want to set the backgroundcolor of text with the
> Mark> set_backgroundcolor function. Does that actually work? I
> Mark> saw a more complicated way to do it by defining a bbox, but
> Mark> this would be much easier (if I got it to work). Here's my
> Mark> example that doesn't work. Thanks for any suggestions,
>
> Strange. When I saw your post my first thought was "hmmm, I didn't
> know we had a text background color". I looked through the text.py
> code and it is there as a property, but is totally unused. I don't
> know who added it, but apparently someone got interrupted mid-code.
> That someone could be me, but if anyone knows where this came from
> speak up; otherwise it will be removed.
>
> The bbox is the standard way to do this, and is a bit more general
> since you can set the alpha, the linewidth, the edgecolor, etc...
>
> ax.text(1,2,'hi mom', bbox=dict(facecolor='red'))
>
> JDH
>

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> Hello - I want to set the backgroundcolor of text with the
 Mark> set_backgroundcolor function. Does that actually work? I
 Mark> saw a more complicated way to do it by defining a bbox, but
 Mark> this would be much easier (if I got it to work). Here's my
 Mark> example that doesn't work. Thanks for any suggestions,
Strange. When I saw your post my first thought was "hmmm, I didn't
know we had a text background color". I looked through the text.py
code and it is there as a property, but is totally unused. I don't
know who added it, but apparently someone got interrupted mid-code.
That someone could be me, but if anyone knows where this came from
speak up; otherwise it will be removed.
The bbox is the standard way to do this, and is a bit more general
since you can set the alpha, the linewidth, the edgecolor, etc...
 ax.text(1,2,'hi mom', bbox=dict(facecolor='red'))
JDH

Hello -
I want to set the backgroundcolor of text with the set_backgroundcolor
function.
Does that actually work?
I saw a more complicated way to do it by defining a bbox, but this would be
much easier (if I got it to work).
Here's my example that doesn't work.
Thanks for any suggestions,
Mark
from pylab import *
plot([1,2,3])
t = text(1,2,'Hello')
t.set_backgroundcolor('r')
draw()

Fernando and Eric have offered very nice explanations, but I have one 
thing to add:
Fernando Perez wrote:
> hopefully the responsibilities will be:
> 
> - ipython -> interactive work
> - numpy/scipy -> numerics
> - matploblib -> plotting
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
I do something very similar - I really believe in namespaces, "import *" 
is a "bad idea".
However, I also try to avoid pylab altogether, in favor of:
import matplotlib as MPL,
MPL.PlottingStuff()
matplotlib provides the plotting functionality in a nice OO way. pylab 
is essentially a wrapper that provides a Matlab-like procedural 
interface to matplotlib. For me, one of the reasons I use python, rather 
than Matlab is that it is a richer, more feature-full language, 
including OO. Some folks think the procedural approach is better for 
interactive use, but I'm not so sure, and I'm quite sure that the OO 
approach is better for "real programs"
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.
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:
http://sourceforge.net/mailarchive/message.php?msg_id=11033442
(Did that ever get up on the Wiki?, and/or does anyone have other pointers?)
-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...

This should help you understand dpi, font-size, etc.
http://www.scipy.org/Cookbook/Matplotlib/AdjustingImageSize
However, I'm not sure how imshow() and SVG work together -- SVG is just 
that -- "Scalable", it doesn't have a set resolution, and I don't know 
what happens when you embed a raster graphic in it -- can someone offer 
an explanation of what MPL does with imshow and SVG?
-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...

Yo,
> 1) multiple y-scales on the left and right. mpl supports a left and
> right scale (see examples/two_scale.py) but nothing like an
> arbitrary number of scales with arbitrary positioning as you see
> in the plot you attached. This has long been on the wish list
> (and is on the goals web page) but has not yet been implemented.
> This is something chaco does quite well because it is very common
> to make these plots in geophysics. For me it is one of the few
> remaining must-have features for matplotlib 1.0. You could hack
> your own scales using matplotlib lines and text instances. Indeed
> it wouldn't be too hard and if I get some time I'll do a demo
> which may serve as a prototype for refactoring the mpl axis code.
I remember that, for a paper, I succeeded to plot two horizontal 
axis, on the bottom of the plot (see the image in attachment)
The difference with my previous mail is that the second axis (labeled 
'compression ratio') is not used for plotting. It is, actually, the 
same than the other axis (labeled 'filter size') but it gives another 
scale/kind of information.
Here is my (very ugly) code:
from pylab import *
from matplotlib.font_manager import *
list = [0.78125356, 0.78125356, 0.78125356, 0.78125356, 0.78125356, 
0.78125356, 0.78125356, 0.78125356, 0.78125356, 0.78125356]
yprops = dict(rotation=0, 
horizontalalignment='right',verticalalignment='center',x=-0.01)
axprops = dict(yticks=[])
rc('text', usetex=True)
rc('lines', markersize=16)
rc('legend', numpoints=3)
#getting data from different source files
tabBF = load('Data/Compact/BFCompact.dat')
tabRBF1 = load('Data/Compact/RBFCompact0.01.dat')
tabRBF2 = load('Data/Compact/RBFCompact0.25.dat')
tabRBF3 = load('Data/Compact/RBFCompact0.05.dat')
tabRBF4 = load('Data/Compact/RBFCompact0.1.dat')
xAxis = tabBF[:,0]
succBF = tabBF[:,1]
succRBF1 = tabRBF1[:,1]
succRBF2 = tabRBF2[:,1]
succRBF3 = tabRBF3[:,1]
succRBF4 = tabRBF4[:,1]
fig = figure(1)
#plot the figure
ax1 = fig.add_axes([0.1,0.2,0.8,0.75])
llist = ax1.plot(xAxis, list, 'k-', linewidth=1.5)
bf = ax1.plot(xAxis, succBF, 'k-x', linewidth=1.5)
rbf1 = ax1.plot(xAxis, succRBF1, 'r-d', linewidth=1.5)
rbf2 = ax1.plot(xAxis, succRBF2, 'b-^', linewidth=1.5)
rbf3 = ax1.plot(xAxis, succRBF3, 'g-<', linewidth=1.5)
rbf4 = ax1.plot(xAxis, succRBF4, 'm-o', linewidth=1.5)
axis([9, 101, -0.01, 1.01], font)
ax1.set_xlabel(r'\textbf{filter size (x 10}$^\mathbf{3}$\textbf{)}', 
font)
ax1.set_ylabel(r'\textbf{success rate}', font)
#ugly way of drawing the legend legend
leg = legend((llist[0], rbf2[0],rbf4[0], rbf3[0], rbf1[0], bf[0]), 
(r'\textbf{list}', r'\textbf{rbf -} $\beta$\textbf{=25\%}', r'\textbf 
{rbf -} $\beta$\textbf{=10\%}',r'\textbf{rbf - }$\beta$\textbf{=5\ 
%}', r'\textbf{rbf - }$\beta$\textbf{=1\%}', r'\textbf{bf}'), loc= 
(0.65,0.23), prop=FontProperties(size='26', weight='bold'))#leg = 
legend((llist[0], bf[0]), (r'\textbf{list}', r'\textbf{bf}'), loc= 
(0.65,0.23), prop=FontProperties(size='26', weight='bold'))
leg.draw_frame(False)
#draw the second x-axis
ax2 = fig.add_axes([0.1,0.1,0.8,0.01], **axprops)
ax2.set_xlabel(r'\textbf{compression ratio}', font)
toto = ['25.6', '12.8', '8.5', '6.4', '5.1', '4.2', '3.6', '3.2', 
'2.8', '2.5']
ax2.get_xaxis().set_ticks(arange(10))
ax2.get_xaxis().set_ticklabels(toto)
savefig('Success3')
This is clearly a hack (and I'm not very proud of it :-( ).
Benoit

>>>>> "Benoit" == Benoit Donnet <do...@in...> writes:
 Benoit> Do you think it is possible to do such a plot in
 Benoit> matplotlib?
Hey Benoit -- thanks for posting that image. It's good to get some
reminders of the current limitations of mpl so we can focus on
improving them. There are two things in that plot that mpl cannot
currently do.
 1) multiple y-scales on the left and right. mpl supports a left and
 right scale (see examples/two_scale.py) but nothing like an
 arbitrary number of scales with arbitrary positioning as you see
 in the plot you attached. This has long been on the wish list
 (and is on the goals web page) but has not yet been implemented.
 This is something chaco does quite well because it is very common
 to make these plots in geophysics. For me it is one of the few
 remaining must-have features for matplotlib 1.0. You could hack
 your own scales using matplotlib lines and text instances. Indeed
 it wouldn't be too hard and if I get some time I'll do a demo
 which may serve as a prototype for refactoring the mpl axis code.
 2) the horizontal legend layout - matplotlib is not very flexible in
 the legend layout and supports only vertical legends. This would
 be a nice feature. Currently the legend code can best be
 described as hairy, which is why few want to try to improve it.
As for the text table at the bottom, you could either do this with
table, probably your best choice, or with a series of side-by-side
axes, or with some custom rectangles and text instances. We've talked
before that it would be nice to have a layout engine, much like the
gtk hbox and vbox, and this would be a good candidate for it.
JDH

Hi all,
First of all, best wishes for the brand new year! I hope that 2007 
will be a great year for all of you.
Attached to this mail, there is an image representing a 'complex 
plot'. this is complex because it contains a lot of information 
(plot + table below the plot). I think the plot + table is not so 
difficult to do using matplotlib (the example table_demo.py should 
give an idea of the solution).
What is, in my opinion more is:
- the fact that the plot contains 6 vertical axis (three on the left 
and three on the right).
- the legend is above the plot and is composed of color boxes that 
refer to a given axis and line on the plot.
Do you think it is possible to do such a plot in matplotlib?
Thanks in advance for any kind of help and thanks again for the 
matplotlib library!
Best regards.
Benoit

Eric, John - thanks for your tips, it works!
petr
On Tue, 2007年01月02日 at 21:01, Eric Firing wrote:
> John Hunter wrote:
> Examples of the shrink kwarg are examples/image_masked.py and 
> examples/contour_demo.py.
> 
> As an alternative to using the shrink kwarg you can always specify axes 
> positions manually. One example is in examples/multi_image.py. 
> Attached is another example modified from image_masked.py.
>
> I have added a bit to the docstring to emphasize the function of the 
> shrink kwarg. This will usually be the easiest manual solution to the 
> problem. I have also thought a bit about adding functionality to the 
> axes.draw() method that would allow the colorbar height to track the 
> height of the mappable axes object; maybe I will try it later.
> 

belinda thom wrote:
> Hi,
> 
> Is there a way for me to keep adding the next row of a 2d array to a 
> file via load? (matlab's save had a very useful -append option).
> 
> I managed to get 2d laod/save working, e.g.
> 
> import numpy as N
> import pylab as P
> import bthom.utils as U
> # a numpy 2d array
> a = N.arange(12,dtype=N.float).reshape((3,4))
> a[0][0] = N.pi
> # checking out the matploblib save/load stuff
> P.save("data.csv", a, fmt="%.4f", delimiter=";")
> aa = P.load("data.csv", delimiter= ";")
> x,y,z,w = P.load("data.csv", delimiter=";", unpack=True)
> 
> The above took me longer than it perhaps should have b/c of advice 
> I'd gotten elsewhere recommending trying to keep numpy and pylab 
> separate when possible (to take advantage of all of numpy's features; 
> it seems numpy doesn't even have the all-to-handy load/save 
> functionality).
> 
> When I try similar tricks to write one row at a time, I'm hosed in 
> that the shape is gone:
> 
> # checking out a way to keep appending
> fname = "data1.csv"
> U.clobber_file(fname) #this thing just ensures 0 bytes in file
> f = open(fname,"a")
> nrows,ncols = a.shape
> for i in range(nrows) :
> P.save(f, a[i,:], fmt="%d", delimiter=";")
> f.close()
> aaa = P.load("data1.csv", delimiter= ";")
> 
> in particular:
> 
> % cat data1.csv
> 3
> 1
> 2
> 4
> <snip>
> 11
> 
> Thanks in advance,
> --b
> 
This is because pylab.save() writes every 1D-array (like a[i,:]) as 
"column vector". In the definition of the save() function:
[...]
 if len(X.shape)==1:
 origShape = X.shape
 X.shape = len(X), 1
[...]
This reshapes the 1D-array (len(a[i,:].shape) == 1) to a 2D-array of 
shape Nx1 and a loop over the first axis writes the rows (in this case 
one element per row) to file.
There are several ways to do what you want:
#-----------------------------------------------------------------------#
# generate data
a = N.arange(12,dtype=N.float).reshape((3,4))
a[0][0] = N.pi
P.save("data.csv", a, fmt="%.4f", delimiter=";")
# (A)
# rather hackish way, define your own save(), not
# really useful, just to show that it works
def save2(fname, X, fmt='%.18e',delimiter=' '):
 if is_string_like(fname):
 if fname.endswith('.gz'):
 import gzip
 fh = gzip.open(fname,'wb')
 else:
 fh = file(fname,'w')
 elif hasattr(fname, 'seek'):
 fh = fname
 else:
 raise ValueError('fname must be a string or file handle')
 X = N.asarray(X)
 origShape = None
 if len(X.shape)==1:
 origShape = X.shape
# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
## X.shape = len(X), 1
 X.shape = 1, len(X)
# <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 for row in X:
 fh.write(delimiter.join([fmt%val for val in row]) + '\n')
 if origShape is not None:
 X.shape = origShape
fname = "data1.csv"
f = open(fname,"a")
nrows,ncols = a.shape
for i in range(nrows) :
 save2(f, a[i,:], fmt="%f", delimiter=";")
f.close()
aaa = P.load("data1.csv", delimiter= ";")
print aaa
print "-----------------------"
# (B)
# do it without a save() function
fname = "data2.csv"
f = open(fname,"a")
nrows,ncols = a.shape
delim = ';'
fmt = '%f'
for i in range(nrows):
 # just like in pylab.save()
 f.write(delim.join([fmt %val for val in a[i,:]]) + '\n')
f.close()
aaa = P.load("data2.csv", delimiter= ";")
print aaa
print "-----------------------"
# (C)
# probably the best: save a 1xn "row vector" per line
fname = "data3.csv"
f = open(fname,"a")
nrows,ncols = a.shape
for i in range(nrows) :
 P.save(f, a[i,:].reshape((1,ncols)), fmt="%f", delimiter=";")
f.close()
aaa = P.load("data3.csv", delimiter= ";")
print aaa
HTH
-- 
cheers,
steve
Random number generation is the art of producing pure gibberish as 
quickly as possible.

Hi,
Is there a way for me to keep adding the next row of a 2d array to a 
file via load? (matlab's save had a very useful -append option).
I managed to get 2d laod/save working, e.g.
 import numpy as N
 import pylab as P
 import bthom.utils as U
 # a numpy 2d array
 a = N.arange(12,dtype=N.float).reshape((3,4))
 a[0][0] = N.pi
 # checking out the matploblib save/load stuff
 P.save("data.csv", a, fmt="%.4f", delimiter=";")
 aa = P.load("data.csv", delimiter= ";")
 x,y,z,w = P.load("data.csv", delimiter=";", unpack=True)
The above took me longer than it perhaps should have b/c of advice 
I'd gotten elsewhere recommending trying to keep numpy and pylab 
separate when possible (to take advantage of all of numpy's features; 
it seems numpy doesn't even have the all-to-handy load/save 
functionality).
When I try similar tricks to write one row at a time, I'm hosed in 
that the shape is gone:
 # checking out a way to keep appending
 fname = "data1.csv"
 U.clobber_file(fname) #this thing just ensures 0 bytes in file
 f = open(fname,"a")
 nrows,ncols = a.shape
 for i in range(nrows) :
 P.save(f, a[i,:], fmt="%d", delimiter=";")
 f.close()
 aaa = P.load("data1.csv", delimiter= ";")
in particular:
 % cat data1.csv
 3
 1
 2
 4
 <snip>
 11
Thanks in advance,
--b

Hi,
The documentation for pylab.load mentions the load_demo.py example.
I can't find this on my distribution. I believe all Pylab examples 
live in site-packages/doc/matplotlib, for in there are files like 
log_demo.py (the only file that begins with load is 
load_converter.py, which is demonstrating using dates).
Does anyone have access to load_demo.py or does it not exist (in 
which case the documentation for load should be modified)?
Thanks,
--b