matplotlib-users Mailing List for matplotlib

Any idea how easy it will be to use matplotlib with scipy_core (rather
than Numeric and numarray)? Will it just be a matter of replacing the
import statements?
Chris

John Hunter wrote:
> Well, it's used to control the figure dpi <wink>. It is used
> everywhere, it's just that savefig changes it when saving and then
> restores it. Basically, it is done this way to support a default
> screen dpi and a default hardcopy dpi.
Fair enough, but my expectation is that when I called savefig, I'd get 
the same resolution as the screen, unless I specified otherwise. If 
savefig used the Figure dpi as the default, but allowed it to be 
overridden (like it does) then we could all be happy. However, if 
there's one thing I've learned about usability, it's that different 
people have different expectations, so what you have might fit other 
peoples expectations better, and we can all do what we need to do.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Glad to know you have at least a workaround, though I'd
 Fernando> still like to get this fixed. I'm sure there are people
 Fernando> who _need_ gtk for other reasons, and thus can't switch
 Fernando> backends. The fact that the bug only appears with
 Fernando> specific combinations of matplotlib version, OS and
 Fernando> connection type (as I said, an SSH login with tunneled
 Fernando> X11 doesn't show it on a system which does show it at
 Fernando> the console), makes this problem all the more
 Fernando> frustrating.
Hey, maybe I should fly out to Boulder and take a look :-)
JDH

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> So what is figure.dpi used for? And I need to ask, why
 Chris> doesn't savefig default to the Figure dpi?
Well, it's used to control the figure dpi <wink>. It is used
everywhere, it's just that savefig changes it when saving and then
restores it. Basically, it is done this way to support a default
screen dpi and a default hardcopy dpi.
 Chris> Thanks. I think I'll update my demo and maybe post it to
 Chris> the Wiki.
Thanks,
JDH

Cory Davis wrote:
> Thanks Fernando,
> I was pleasantly surprised to find that TkAgg works on my RHEL4 system 
> without me troubling our system administrators. If it helps, ipython, 
> matplotlib and GTKAgg work fine on my Fedora Core 2 laptop.
Glad to know you have at least a workaround, though I'd still like to get this 
fixed. I'm sure there are people who _need_ gtk for other reasons, and thus 
can't switch backends. The fact that the bug only appears with specific 
combinations of matplotlib version, OS and connection type (as I said, an SSH 
login with tunneled X11 doesn't show it on a system which does show it at the 
console), makes this problem all the more frustrating.
Cheers,
f

John Hunter wrote:
> Sorry Chris, I got half way through answering this a few days ago but
> had to take off midstream, and though I thought I had saved the post,
> it was lost. Trying again.
thanks, you're usually so responsive, I was surprised!
> Chris> Figure.set_dpi( val )
> 
> Yep. But you have to be careful here, because savefig has it's own
> default dpi, so when creating hardcopy you will need to explicitly set dpi.q
So what is figure.dpi used for? And I need to ask, why doesn't savefig 
default to the Figure dpi?
Thanks. I think I'll update my demo and maybe post it to the Wiki.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Thanks Fernando,
I was pleasantly surprised to find that TkAgg works on my RHEL4 system 
without me troubling our system administrators. If it helps, ipython, 
matplotlib and GTKAgg work fine on my Fedora Core 2 laptop.
Cheers,
Cory.
Fernando Perez wrote:
> Cory Davis wrote:
> 
>> Hi All,
>> some time ago I lost the ability to plot anything from within ipython. 
>> For example ...
>>
>> In [1]:from pylab import *
>>
>> In [2]:plot(range(20),range(20))
>> --------------------------------------------------------------------------- 
>>
>> exceptions.SystemError Traceback (most 
>> recent call last)
>>
>>
>> SystemError: Objects/moduleobject.c:48: bad argument to internal function
>> Segmentation fault
>>
>> The above occurs both with "ipython -pylab" and also "ipython" with 
>> the ahow() command at the end. Thankfully everything works with the 
>> vanilla python interpreter.
>>
>> Its possible that this became broken after changing my OS to Redhat 
>> EL4. Updating to the SVN version of ipython has not helped.
>> I have python 2.3.4, and matplotlib 0.83.2
>>
>> Has anyone seen anything like this?
> 
> 
> I have: it's a GTK-backend only bug, as far as I've seen. I normally 
> don't use GTK, so it doesn't bother me too much. You can work around 
> the problem by switching to any other backend (TkAgg, WXAgg, QtAgg will 
> all do).
> 
>> Any advice?
> 
> 
> The problem is _extremely_ strange, and the nastiest part is that John 
> hasn't been able to see it. I even gave him an account on one of my 
> local system, and the bug doesn't appear for him when SSH'd into 
> Colorado from Chicago (he can display plot windows over X11), though I 
> do see it logged in as his user at the console.
> 
> This can't be explicitly an ipython bug, since ipython is pure python 
> code (so it can't segfault by itself), but it's most likely a threading 
> problem triggered by ipython. John and I are at a loss as to what can 
> be going on here, and any ideas would be most welcome.
> 
> I may try to dig deeper into it, but since I don't know my way around 
> the pygtk and maptlotlib gtk codes, I'm not terribly hopeful (and it 
> won't be done until I clear the big backlog of ipython issues I have on 
> my plage).
> 
> Sorry not to be able to offer a better answer right now...
> 
> Regards,
> 
> f
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
---------------------------------------------------
Cory Davis
Institute for Atmospheric and Environmental Science
Room 307, Crew Building, Kings Buildings,
University of Edinburgh. Edinburgh EH9 3JN
phone: +44 131 6505092
www: http://www.geos.ed.ac.uk/contacts/homes/cdavis

John,
Since this appears to be a recurrent problem, would it not be better to tes=
t
for a string and then not do the iteration. In other words, the iteration
should be done only for lists and tuples.
-- Paul
On 9/30/05, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Christian" =3D=3D Christian Meesters <mee...@un...> write=
s:
>
> Christian> Hi, I'm looping over a list like this
> Christian> ['name',[data_array],'name2',[data_array2],...] like
> Christian> this:
>
> Christian> for x,y in zip(toplot_list,linestyles): if type(x) =3D=3D
> Christian> type(array([])): pylab.plot(wavelengths,x,'k%s'% y)
> Christian> pylab.legend(toplot_list[toplot_list.index(x)-1])
>
> Christian> Now there is a problem with the legend, that I don't
> Christian> see all names, but only the last. I seems to me like
> Christian> the names get superposed, though I cannot see
> Christian> this. Anyway, if I have a name like 'hello' the entry
> Christian> in the legend looks like: h e l l o Well, this is not
> Christian> quite the behaviour I wanted. Does anybody know how to
> Christian> increase the size of the legend automatically so that
> Christian> all names can be written out? Or is it possible to
> Christian> prevent line break somehow?
>
> Call the legend outside the list with a list of lines and labels you
> want to pass to it. The strange 'hello' artifact you are seeing is
> because 'hello' is a string and the legend code is iterating over it.
>
> Something like
>
> lines =3D []
> labels =3D []
> for val in something:
> lines.extend(plot(val))
> labels.append(somelabel)
> legend(lines, labels)
>
>
> Or using autolegend
> for val in something:
> plot(val, label=3Dsomelabel)
> legend()
>
>
> JDH
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Cory Davis wrote:
> Hi All,
> some time ago I lost the ability to plot anything from within ipython. 
> For example ...
> 
> In [1]:from pylab import *
> 
> In [2]:plot(range(20),range(20))
> ---------------------------------------------------------------------------
> exceptions.SystemError Traceback (most 
> recent call last)
> 
> 
> SystemError: Objects/moduleobject.c:48: bad argument to internal function
> Segmentation fault
> 
> The above occurs both with "ipython -pylab" and also "ipython" with the 
> ahow() command at the end. Thankfully everything works with the vanilla 
> python interpreter.
> 
> Its possible that this became broken after changing my OS to Redhat EL4. 
> Updating to the SVN version of ipython has not helped.
> I have python 2.3.4, and matplotlib 0.83.2
> 
> Has anyone seen anything like this?
I have: it's a GTK-backend only bug, as far as I've seen. I normally don't 
use GTK, so it doesn't bother me too much. You can work around the problem by 
switching to any other backend (TkAgg, WXAgg, QtAgg will all do).
> Any advice?
The problem is _extremely_ strange, and the nastiest part is that John hasn't 
been able to see it. I even gave him an account on one of my local system, 
and the bug doesn't appear for him when SSH'd into Colorado from Chicago (he 
can display plot windows over X11), though I do see it logged in as his user 
at the console.
This can't be explicitly an ipython bug, since ipython is pure python code (so 
it can't segfault by itself), but it's most likely a threading problem 
triggered by ipython. John and I are at a loss as to what can be going on 
here, and any ideas would be most welcome.
I may try to dig deeper into it, but since I don't know my way around the 
pygtk and maptlotlib gtk codes, I'm not terribly hopeful (and it won't be done 
until I clear the big backlog of ipython issues I have on my plage).
Sorry not to be able to offer a better answer right now...
Regards,
f

Thanks John, works great.
> Since this appears to be a recurrent problem, would it not be better 
> to test for a string and then not do the iteration. In other words, 
> the iteration should be done only for lists and tuples.
Well Paul, I guess this is my fault, I should have known better by 
know. But I actually think you are right: Since its not really self 
explaining and people are making the same mistake over and over again 
(me even twice, arrgh!), it's worth to consider your idea.
Cheers,
Christian

>>>>> "david" == david trem <dav...@fr...> writes:
 david> Hi again, Will be better with a subject, (sorry for the
 david> pollution)
 david> I'm looking for a way to remove and/or control the
 david> properties (color, thickness,...) of the lines (axis)
 david> around the graph. I spent already quite some time to
 david> search a solution. I have found only one comment on these
 david> lines in the multiline-plot wiki: "It's on our list of
 david> things to change the way these axes lines are draw so that
 david> you can remove it, but it isn't done yet"
 david> Is this done now? Is there even a dirty trick to at least
 david> remove them?
You can make the edge color of the rectangle patch the same color as
the facecolor
ax.axesPatch.set_facecolor('g')
ax.axesPatch.set_edgecolor('g')
ax.axesPatch.set_linewidth(0)
For more control, you can do something like
from matplotlib.numerix import arange, sin, pi
from pylab import figure, show
fig = figure()
ax = fig.add_subplot(111, xlim=(-1,1), ylim=(-1,1),
 xticks=[], yticks=[],
 frameon=False, autoscale_on=False)
ax.axvline(0, color='k', lw=2)
ax.axhline(0, color='k', lw=2)
ax.text(0.0, 0.0, '(0,0)')
ax.text(0.0, 1.0, '(0,1)')
ax.text(1.0, 0.0, '(1,0)')
t = arange(-1,1,0.01)
ax.plot(t,sin(2*pi*t), lw=1, color='b')
show()
JDH

>>>>> "Dev" == Dev Gorur <dg...@gm...> writes:
 Dev> Here are two almost identical bits of code. The first one
 Dev> prints the title. The second doesn't. It's really baffling.
 Dev> ------------------------------ from pylab import * import
 Dev> string from matplotlib import rc
This looks like a duplicate of bug
http://sourceforge.net/tracker/index.php?func=detail&aid=1296124&group_id=80706&atid=560720
Hopefully one of can take a look soon. Caching problem, perhaps?
JDH

>>>>> "Yannick" == Yannick Copin <yan...@la...> writes:
 Yannick> Hi, I have a bug when I want to turn off the tick labels
 Yannick> on subplots where upper limits reaches 10000: the
 Yannick> "magnitude" string (x1e4) doesn't get erased. Example:
You can make the "offsetText" instance invisible too
 from pylab import *
 ax1 = subplot(2,2,1)
 plot(arange(0,11000,1000),arange(0,11000,1000))
 invisible = ax1.get_xticklabels() + ax1.get_xticklabels()
 invisible.append(ax1.xaxis.offsetText)
 ax2 = subplot(2,2,2)
 plot(arange(0,11000,1000),arange(0,11000,1000),'--')
 invisible.extend( ax2.get_xticklabels() + ax2.get_xticklabels() )
 invisible.append(ax2.xaxis.offsetText)
 setp(invisible, visible=False)
 ax3 = subplot(2,2,3)
 plot(arange(0,11000,1000),arange(0,11000,1000),':')
 ax4 = subplot(2,2,4)
 plot(arange(0,11000,1000),arange(0,11000,1000),'-.')
 setp(ax4.get_yticklabels(), visible=False)
 show()

>>>>> "Gabriele" == Gabriele Farina *DarkBard* <Gabriele> writes:
 Gabriele> Hi, I just started to use matplotlib for a small project
 Gabriele> involving graph generation. I'd like you to help me to
 Gabriele> solve a simple problem: I assign to axes values that
 Gabriele> range from 0 to 100 bilion. The library approximate the
 Gabriele> values to fit correctly the layout, an it places the
 Gabriele> exponent that should be used to retrieve the right value
 Gabriele> on top of the axes. I need to change this behaviour, and
 Gabriele> I'd like matplotlib to show the full exponent (1000
 Gabriele> instead of x1e3 for example).
See the users guide section on tick locators and formatters, and the
examples showing how to use tick formatters
> grep -l Formatter *.py
custom_ticker1.py
dashtick.py
date_demo1.py
date_demo2.py
date_demo_rrule.py
finance_demo.py
major_minor_demo1.py
major_minor_demo2.py
newscalarformatter_demo.py
shared_axis_demo.py
JDH

>>>>> "Ryan" == Ryan Krauss <rya...@co...> writes:
 Ryan> And can I make one legend that includes the plots from both
 Ryan> axes?
Save a list of lines and a list of labels and then call
 ax.legend(lines, labels)
lines and labels can be from different axes; eg,
 lines = []
 lines.extend( ax1.plot(something))
 lines.extend( ax2.plot(something_else))
See also the figure legend capability in
http://matplotlib.sf.net/matplotlib.figure.html
 Ryan> Thanks for your help John. I think I am getting close to a
 Ryan> really nice graph with a lot of useful information on it.
Your welcome -- good luck.
JDH

>>>>> "Christian" == Christian Meesters <mee...@un...> writes:
 Christian> Hi, I'm looping over a list like this
 Christian> ['name',[data_array],'name2',[data_array2],...] like
 Christian> this:
 Christian> for x,y in zip(toplot_list,linestyles): if type(x) ==
 Christian> type(array([])): pylab.plot(wavelengths,x,'k%s'% y)
 Christian> pylab.legend(toplot_list[toplot_list.index(x)-1])
 Christian> Now there is a problem with the legend, that I don't
 Christian> see all names, but only the last. I seems to me like
 Christian> the names get superposed, though I cannot see
 Christian> this. Anyway, if I have a name like 'hello' the entry
 Christian> in the legend looks like: h e l l o Well, this is not
 Christian> quite the behaviour I wanted. Does anybody know how to
 Christian> increase the size of the legend automatically so that
 Christian> all names can be written out? Or is it possible to
 Christian> prevent line break somehow?
Call the legend outside the list with a list of lines and labels you
want to pass to it. The strange 'hello' artifact you are seeing is
because 'hello' is a string and the legend code is iterating over it. 
Something like
lines = []
labels = []
for val in something:
 lines.extend(plot(val))
 labels.append(somelabel)
legend(lines, labels)
Or using autolegend
for val in something:
 plot(val, label=somelabel)
legend()
JDH

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> Hi all, I sent pretty much this question a couple days ago,
 Chris> but it was tacked on to another thread, so it may have
 Chris> gotten lost in the shuffle. So here it is again:
Sorry Chris, I got half way through answering this a few days ago but
had to take off midstream, and though I thought I had saved the post,
it was lost. Trying again.
 Chris> This is how I thought MPL works, but it turns out I'm
 Chris> wrong, as the example below indicates. What have I got
 Chris> wrong?
 Chris> 1) The size of a figure is defined in length units
 Chris> (inches), and can be set by:
 Chris> Figure.set_figsize_inches( (w,h) )
Yep.
 Chris> 1b) The layout of the figure is defined in "figure units"
 Chris> so it can be scaled by changing the figure size.
Not sure what this means, but you can change the figure size and the
layout (eg axes positions) will update.
 Chris> 2) Size of text, width of lines, etc is defined in terms of
 Chris> length units (points?).
Yes, points.
 Chris> 3) When displaying to the screen, or creating an image
 Chris> (PNG) the pixel size of text and line widths, etc is
 Chris> determined by the dpi setting, which is set by:
 Chris> Figure.set_dpi( val )
Yep. But you have to be careful here, because savefig has it's own
default dpi, so when creating hardcopy you will need to explicitly set dpi.q
 Chris> The trick here is that when printing, it's natural to think
 Chris> in terms of inches, but when creating an image (for a web
 Chris> page, for instance), it is natural to think in terms of
 Chris> pixel size. However, AFAIK, MPL does not have a way to set
 Chris> the pixel size directly.
It does now. In 0.84 I added a canvas.resize(w,h) in pixels. So far
this has only been implemented in GTK*. If anyone wants to help with
the other backends, that would be great. See the thread on the dev
list "GUI maintainers: canvas.resize and ResizeEvent"
With the changes in that post, you can dynamically resize the canvas
or figure, eg from the interactive shell, and the GUI figure window
will update, as it should.
 Chris> However, changing the dpi of the Figure doesn't seem to
 Chris> have any effect. What's up John? shouldn't Figure.set_dpi
 Chris> effect the dpi of the resulting PNG? I'm using MPL 0.84 on
 Chris> Linux.
See the comment on savefig above.
Cheers,
JDH

Hi All,
some time ago I lost the ability to plot anything from within ipython. 
For example ...
In [1]:from pylab import *
In [2]:plot(range(20),range(20))
---------------------------------------------------------------------------
exceptions.SystemError Traceback (most 
recent call last)
SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault
The above occurs both with "ipython -pylab" and also "ipython" with the 
ahow() command at the end. Thankfully everything works with the vanilla 
python interpreter.
Its possible that this became broken after changing my OS to Redhat EL4. 
 Updating to the SVN version of ipython has not helped.
I have python 2.3.4, and matplotlib 0.83.2
Has anyone seen anything like this?
Any advice?
Cheers,
Cory.
-- 
---------------------------------------------------
Cory Davis
Institute for Atmospheric and Environmental Science
Room 307, Crew Building, Kings Buildings,
University of Edinburgh. Edinburgh EH9 3JN
phone: +44 131 6505092
www: http://www.geos.ed.ac.uk/contacts/homes/cdavis

Chris Fonnesbeck wrote:
> I have successfully built and installed wxPython, so that I can use 
> the WXAgg backend for matplotlib. Now, trying to build matplotlib, I 
> get the following error:
>
> /usr/bin/g++ -bundle -undefined dynamic_lookup build/temp.darwin- 
> 8.2.0-Power_Macintosh-2.4/src/_na_transforms.o 
> build/temp.darwin-8.2.0-Power_Macintosh-2.4/src/mplutils.o 
> build/temp.darwin-8.2.0-Power_Macintosh-2.4/CXX/cxx_extensions.o 
> build/temp.darwin-8.2.0-Power_Macintosh-2.4/CXX/cxxsupport.o 
> build/temp.darwin-8.2.0-Power_Macintosh-2.4/CXX/IndirectPythonInterface.o 
> build/temp.darwin-8.2.0-Power_Macintosh-2.4/CXX/cxxextensions.o 
> -L/usr/local/lib -L/usr/lib -lstdc++ -lm -o 
> build/lib.darwin-8.2.0-Power_Macintosh-2.4/matplotlib/_na_transforms.so
> ld: build/temp.darwin-8.2.0-Power_Macintosh-2.4/src/_na_transforms.o 
> illegal reference for -dynamic code (section difference reference from 
> section (__TEXT,__eh_frame) relocation entry (20) to symbol: 
> __ZSt21_Rb_tree_rotate_rightPSt18_Rb_tree_node_baseRS0_ defined in 
> dylib: /usr/local/lib/libstdc++.dylib)
> ld: build/temp.darwin-8.2.0-Power_Macintosh-2.4/src/_na_transforms.o 
> illegal reference for -dynamic code (section difference reference from 
> section (__TEXT,__eh_frame) relocation entry (24) to symbol: 
> __ZSt20_Rb_tree_rotate_leftPSt18_Rb_tree_node_baseRS0_ defined in 
> dylib: /usr/local/lib/libstdc++.dylib)
> error: command '/usr/bin/g++' failed with exit status 1
>
> I am using gcc 3.3, and ActivePython 2.4.1.
>
> Any ideas as to what is going wrong?
Chris:
I got around this in the fink package by setting 'export CXX=gcc'.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Hi,
I'm looping over a list like this 
['name',[data_array],'name2',[data_array2],...] like this:
for x,y in zip(toplot_list,linestyles):
 if type(x) == type(array([])):
 pylab.plot(wavelengths,x,'k%s'% y)
 pylab.legend(toplot_list[toplot_list.index(x)-1])
Now there is a problem with the legend, that I don't see all names, but 
only the last. I seems to me like the names get superposed, though I 
cannot see this. Anyway, if I have a name like 'hello' the entry in the 
legend looks like:
h
e
l
l
o
Well, this is not quite the behaviour I wanted.
Does anybody know how to increase the size of the legend automatically 
so that all names can be written out? Or is it possible to prevent line 
break somehow?
TIA
Christian

Hi all,
I sent pretty much this question a couple days ago, but it was tacked on
to another thread, so it may have gotten lost in the shuffle. So here it
is again:
This is how I thought MPL works, but it turns out I'm wrong, as the
example below indicates. What have I got wrong?
1) The size of a figure is defined in length units (inches), and can be
set by:
 Figure.set_figsize_inches( (w,h) )
1b) The layout of the figure is defined in "figure units" so it can be
scaled by changing the figure size.
2) Size of text, width of lines, etc is defined in terms of length units
(points?).
3) When displaying to the screen, or creating an image (PNG) the pixel
size of text and line widths, etc is determined by the dpi setting,
which is set by:
Figure.set_dpi( val )
The trick here is that when printing, it's natural to think in terms of
inches, but when creating an image (for a web page, for instance), it is
natural to think in terms of pixel size. However, AFAIK, MPL does not
have a way to set the pixel size directly.
However, changing the dpi of the Figure doesn't seem to have any effect.
What's up John? shouldn't Figure.set_dpi effect the dpi of the resulting
PNG? I'm using MPL 0.84 on Linux.
-Chris
Enclosed is a sample script, and below are the results:
> (7.9749999999999996, 5.6624999999999996) Which should result in a 638
> x 453 Image DPI: 160.0 Size in Inches (7.9749999999999996, 
> 5.6624999999999996) Which should result in a 1276 x 906 Image DPI: 
> 160.0 Size in Inches (16.0, 12.0) Which should result in a 2560 x 
> 1920 Image DPI: 80.0 Size in Inches (16.0, 12.0)
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> #!/usr/bin/env python2.4
> 
> import matplotlib print "using MPL version:", matplotlib.__version__ 
> matplotlib.use("WXAgg")
> 
> import pylab import Numeric as N
> 
> x = N.arange(0, 2*N.pi, 0.1) y = N.sin(x)
> 
> 
> pylab.plot(x,y) F = pylab.gcf()
> 
> # Save with the defaults DPI = F.get_dpi() print "DPI:", DPI Size = 
> F.get_size_inches() print "Size in Inches", Size print "Which should
> result in a %i x %i Image"%(DPI*Size[0], DPI*Size[1]) 
> F.savefig("test1.png") # this gives me a 797 x 566 pixel image, which
> isn't seem right. # these numbers correspond to 100 DPI
> 
> # Now change the DPI: F.set_dpi(160) DPI = F.get_dpi() print "DPI:",
> DPI Size = F.get_size_inches() print "Size in Inches", Size print 
> "Which should result in a %i x %i Image"%(DPI*Size[0], DPI*Size[1]) 
> F.savefig("test2.png") # this still gives me a 797 x 566 pixel image.
> # The DPI of the figure is not being used.
> 
> #Now change the Size: F.set_figsize_inches( (16.0, 12.0) ) DPI = 
> F.get_dpi() print "DPI:", DPI Size = F.get_size_inches() print "Size
> in Inches", Size print "Which should result in a %i x %i 
> Image"%(DPI*Size[0], DPI*Size[1]) F.savefig("test1.png") # this gives
> me a 1600 x 1200 pixel image, # which still corresponds to 100 DPI
> 
> # Now change dpi again: F.set_dpi(80) print "DPI:", F.get_dpi() print
> "Size in Inches", F.get_size_inches() F.savefig("test4.png") # Same
> image, not change.
> 
> 
> 
> 
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Thu, 2005年09月29日 at 19:54 -0500, Charlie Moad wrote:
> I'll commit that patch, but first I have one question. Why do you
> cast X and Y to Float64 types? You should technically be able to plot
> a vector field with integer components.
You're correct, they shouldn't be cast to Float64. Generally, when I run
into data problems, I cast my arrays into Float types so I don't get bit
by integer division. I tried doing that in this case and forgot to undo
my change when it didn't work. Sorry about that.
Feel free to remove the end of line comments I added as well. I just
realized I didn't remove them when I made the patch.
Regards,
John
--
John Byrnes (by...@bu...)
Graduate Student
Electrical Engineering
Boston University
You should never wear your best trousers when you go out to fight for
freedom and liberty.
		-- Henrik Ibsen

 I'll commit that patch, but first I have one question. Why do you
cast X and Y to Float64 types? You should technically be able to plot
a vector field with integer components.
Thanks,
 Charlie
On 9/29/05, John Byrnes <by...@bu...> wrote:
> Sorry, didn't attach the file.
>
> John
> On Thu, 2005年09月29日 at 19:31 -0400, John Byrnes wrote:
> > On Thu, 2005年09月29日 at 12:43 -0400, John Byrnes wrote:
> > > around line 855 or so in axes.py
> > >
> > > N =3D sqrt( U**2+V**2 )
> > > if do_scale:
> > > Nmax =3D maximum.reduce(maximum.reduce(N))
> > > U *=3D (S/Nmax)
> > > V *=3D (S/Nmax)
> > > N /=3D Nmax
> > >
> > > No provision is made for the case where N is the zero vector.
> >
> >
> > I've attached a patch for axes.py and patches.py that takes fixes the
> > behavior of quiver() for zero valued vectors. I'm not sure if it break=
s
> > anything else.
> >
> > Regards,
> >
> > John
> >
> > --
> > John Byrnes (by...@bu...)
> > Graduate Student
> > Electrical Engineering
> > Boston University
> >
> > If you know how to spend less than you get, you have the philosopher's =
stone.
> > -- Benjamin Franklin
>
> --
> John Byrnes (by...@bu...)
> Graduate Student
> Electrical Engineering
> Boston University
>
> The radical invents the views. When he has worn them out the conservative=
 adopts them.
> -- Mark Twain, 'Notebook,' 1935
>
>
>

Sorry, didn't attach the file.
John
On Thu, 2005年09月29日 at 19:31 -0400, John Byrnes wrote:
> On Thu, 2005年09月29日 at 12:43 -0400, John Byrnes wrote:
> > around line 855 or so in axes.py
> > 
> > N = sqrt( U**2+V**2 )
> > if do_scale:
> > 	Nmax = maximum.reduce(maximum.reduce(N))
> > 	U *= (S/Nmax)
> > 	V *= (S/Nmax)
> > 	N /= Nmax
> > 
> > No provision is made for the case where N is the zero vector. 
> 
> 
> I've attached a patch for axes.py and patches.py that takes fixes the
> behavior of quiver() for zero valued vectors. I'm not sure if it breaks
> anything else.
> 
> Regards,
> 
> John
> 
> --
> John Byrnes (by...@bu...)
> Graduate Student
> Electrical Engineering
> Boston University
> 
> If you know how to spend less than you get, you have the philosopher's stone.
> 		-- Benjamin Franklin
--
John Byrnes (by...@bu...)
Graduate Student
Electrical Engineering
Boston University
The radical invents the views. When he has worn them out the conservative adopts them.
		-- Mark Twain, 'Notebook,' 1935

On Thu, 2005年09月29日 at 12:43 -0400, John Byrnes wrote:
> around line 855 or so in axes.py
>=20
> N =3D sqrt( U**2+V**2 )
> if do_scale:
> 	Nmax =3D maximum.reduce(maximum.reduce(N))
> 	U *=3D (S/Nmax)
> 	V *=3D (S/Nmax)
> 	N /=3D Nmax
>=20
> No provision is made for the case where N is the zero vector. =20
I've attached a patch for axes.py and patches.py that takes fixes the
behavior of quiver() for zero valued vectors. I'm not sure if it breaks
anything else.
Regards,
John
--
John Byrnes (by...@bu...)
Graduate Student
Electrical Engineering
Boston University
If you know how to spend less than you get, you have the philosopher's ston=
e.
		-- Benjamin Franklin