matplotlib-users Mailing List for matplotlib (Page 4)

Hi,
when I have a Text instance, how can I get the dimensions of it?
-- 
View this message in context: http://www.nabble.com/How-to-get-Text-dimensions-tp21127748p21127748.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

jouni k seppänen wrote:
> By the way - do all backends support
> arbitrary clip paths now? If so, the
> hatch implementation of backend_ps
> could perhaps be generalized to all
> backends, or it could even be done in
> the Patch class and not the backend.
> 
That's a very good suggestion. All except Gdk support clip paths now. 
So supporting hatching everywhere is definitely something for the TODO list.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I'm currently using Qwt to display a plot in a GUI application, but I'd like
to replace it with matplotlib and a shell window, so that the user can not
only view the plot but also modify it in-place using pyplot commands.
One thing I'd like to do is to adjust the spacing surrounding the plot to be
constant, regardless of the window size. Since the plot window is resized
often, it is impossible to use very small subplot params and a waste of
viewing space to use larger ones when the window is maximized.
Is there a way to make the figure use absolute params like "20 pixels/points"?
Second, less important question: is there a way to give default font properties
(like weight="bold") for axis labels?
Third, I normally get my data one point at a time. Is there a more efficient
way to insert single data points in existing plots than doing
set_xdata/set_ydata?
Thanks,
Georg
-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

On Sat, Dec 20, 2008 at 8:52 AM, jouni k seppänen <jk...@ik...> wrote:
> Also the patch demo or some unit test
> should cover that branch of the code,
> ie the case when more than one patch
> has the same hatch pattern.
I just check in the patch with a slight change in the hatch_demo.py
Regards,
-JJ

On Sat, Dec 20, 2008 at 6:02 PM, Lebostein <Leb...@gm...> wrote:
> A little thing: the shadow of the legend box is not scaling with the dpi.
> For example with 300 dpi I can't discover the shadow...
This also should be fixed in the maintenance branch and the trunk.
Thanks for reporting.
-JJ

OK, now it works! Thank you!
A little thing: the shadow of the legend box is not scaling with the dpi.
For example with 300 dpi I can't discover the shadow...
-- 
View this message in context: http://www.nabble.com/different-PNG-and-PDF-output...-tp21028686p21109783.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thank You!
-- 
View this message in context: http://www.nabble.com/legend%3A-axespad%2C-pad%2C-handlelen%2C-labelsep---without-effect-tp21087472p21109685.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

>
>
> Please try again with the new OS X binaries at
>
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644
>
Clean install of
	matplotlib-0.98.5.2-py2.5-macosx10.5.mpkg
worked fine for me on OS X 10.5.6 MBP Intel 15" with
	python-2.5.2-macosx.dmg
	numpy-1.2.1-py2.5-macosx10.5.dmg
	wxPython2.8-osx-unicode-2.8.9.1-universal-py2.5.dmg
	ipython-0.9.1-py2.5.egg

Thanks John, you hit this one on the head. I forgot I had set all this in my login script. I took it out and it worked like a charm.
-Ryan
>Flags like
>
 > -DANSI -I/usr/local/VNI/imsl/cnl600/linux64/include
>
>indicate to me you have some non-standard stuff in your build
>environment ... try and remove the CFLAGS that are causing the "visual
>numerics" include flags to set.
>
>JDH

Jae-Joon Lee <lee.j.joon@...> writes:
> 
> It seems as a bug in the pdf backend, which can be fixed by the simple
> patch below. I didn't commit this fix as I think it would be better if
> original author (Jouni?) make sure this is a correct way.
Your patch is correct - I probably
copy-pasted the cache code from
some other function and didn't pay
attention to what exactly is being
cached. I am unable to commit myself,
since I am traveling. Please feel free to
commit the fix.
> ps. I didn't know that hatch is supported in pdf backend. The
> documentation needs update.
Also the patch demo or some unit test
should cover that branch of the code,
ie the case when more than one patch
has the same hatch pattern.
By the way - do all backends support
arbitrary clip paths now? If so, the
hatch implementation of backend_ps
could perhaps be generalized to all
backends, or it could even be done in
the Patch class and not the backend.
Jouni

On Sat, Dec 20, 2008 at 1:19 AM, Ryan Wagner <rw...@vn...> wrote:
> Hi guys,
>
> I've been trying to build the newest version of MPL on Ubuntu Intrepid
> for a few days now. I'm not getting anywhere. I believe I have all the
> correct dev packages installed. I had tried to build 0.98.3 but it came out
> via apt-get. Can anyone take a look at my install output (attached) and give
> me an idea of what I may be doing wrong? TIA
>
Do you have SWIG installed?

On Sat, Dec 20, 2008 at 12:19 AM, Ryan Wagner <rw...@vn...> wrote:
> Hi guys,
>
> I've been trying to build the newest version of MPL on Ubuntu Intrepid
> for a few days now. I'm not getting anywhere. I believe I have all the
> correct dev packages installed. I had tried to build 0.98.3 but it came out
> via apt-get. Can anyone take a look at my install output (attached) and give
> me an idea of what I may be doing wrong? TIA
Is it possible you are not using g++ here ? The compile line that is failing is
 cc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -ansi -m64 -w -DCOMPUTER_LOPT64 -DANSI
-I/usr/local/VNI/imsl/cnl600/linux64/include -fPIC
-I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
-I/usr/include/python2.5 -c CXX/cxxextensions.c -o
build/temp.linux-x86_64-2.5/CXX/cxxextensions.o
 In file included from CXX/cxxextensions.c:38:
 ./CXX/WrapPython.h:1: error: expected identifier or '(' before '/' token
The line in question, line 1 of WrapPython.h, is simply a comment.
Flags like
 -DANSI -I/usr/local/VNI/imsl/cnl600/linux64/include
indicate to me you have some non-standard stuff in your build
environment, and perhaps you are picking up a different compiler or
library, perhaps the intel compiler? If you are trying to compile
with the intel compiler, you may need to set the CC and CXX
environment variables to make sure you are using the c++ compiler.
If you can use g++, you are more likely to have success. Before
building, I suggest
 export CC=gcc
 export CXX=g++
You might also try and remove the CFLAGS that are causing the "visual
numerics" include flags to set.
JDH

Nils,
As far as I know, this is not currently a feature.
Josh
On Wed, Dec 10, 2008 at 5:46 AM, Nils Wagner
<nw...@ia...> wrote:
>
>
> --- the forwarded message follows ---
>
>
> ---------- Forwarded message ----------
> From: "Derek Hohls" <DH...@cs...>
> To: "Nils Wagner" <nw...@ia...>
> Date: 2008年12月10日 15:38:37 +0200
> Subject: Re: [Matplotlib-users] [SciPy-user] reading and writing data
> inExcel files
> >From the looks of the mail archive, it seems PyExcelerator is no longer
> maintained
> http://sourceforge.net/mailarchive/forum.php?forum_name=pyexcelerator-devel
>
> You are advised to rather use xlwt to write Excel:
> http://pypi.python.org/pypi/xlwt
> and xlrd to read Excel:
> http://pypi.python.org/pypi/xlrd/
>
> Both maintained by John Machin.
>
>>>> On 2008年12月10日 at 03:11, in message <web...@un...>,
>>>> "Nils Wagner" <nw...@ia...> wrote:
> On 2008年12月10日 04:24:24 -0800
> "Joshua Lippai" <dis...@gm...> wrote:
>> With PyExcelerator installed, you can use the Excel
>>tools in the
>> matplotlib toolkits
>>
>> http://matplotlib.sourceforge.net/users/toolkits.html
>>
>> Using them, you can read in Excel files as recarrays and
>>write
>> recarrays to Excel files. It's fairly well-documented
>>through
>> docstrings.
>>
>> Josh
>>
> Hi Josh,
>
> Thank you for your prompt response !
>
> I found an example in matplotlib/examples/pylab_examples
> loadrec.py
>
> Is it possible to color cells depending on the entry ?
>
> Nils
>
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions, e-mail
> legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner,
> and is believed to be clean. MailScanner thanks Transtec Computers for
> their support.
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

It seems as a bug in the pdf backend, which can be fixed by the simple
patch below. I didn't commit this fix as I think it would be better if
original author (Jouni?) make sure this is a correct way. Neil, your
code will work okay if you don't use hatch. Or, you may apply the
patch by yourself.
-JJ
ps. I didn't know that hatch is supported in pdf backend. The
documentation needs update.
http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.Patch.set_hatch
Index: lib/matplotlib/backends/backend_pdf.py
===================================================================
--- lib/matplotlib/backends/backend_pdf.py	(revision 6687)
+++ lib/matplotlib/backends/backend_pdf.py	(working copy)
@@ -942,4 +942,4 @@
 def hatchPattern(self, lst):
 pattern = self.hatchPatterns.get(lst, None)
 if pattern is not None:
- return pattern[0]
+ return pattern
 name = Name('H%d' % self.nextHatch)
 self.nextHatch += 1
On Sat, Dec 20, 2008 at 2:02 AM, Neil Conway <nr...@cs...> wrote:
> On Sat, Dec 20, 2008 at 1:32 AM, Neil Conway <nr...@cs...> wrote:
>> I see the following error using matplotlib 0.95.1:
>
> Sorry: that should be 0.98.5.1.
>
> Neil
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Sat, Dec 20, 2008 at 1:32 AM, Neil Conway <nr...@cs...> wrote:
> I see the following error using matplotlib 0.95.1:
Sorry: that should be 0.98.5.1.
Neil

Given the following matplotlib program:
##
import numpy as np
import matplotlib.pyplot as plt
x = np.arange(3)
width = 0.35
hdfs = (292.97, 304.49, 305.47)
bfs = (614.57, 706.02, 847.44)
plt.subplot(111)
hdfs_rects = plt.bar(x, hdfs, width, color='b')
bfs_rects = plt.bar(x + width, bfs, width, color='g', hatch='/')
plt.xticks(x + width, ('100 ls ops', '100 touch ops', '100 0k copy ops'))
plt.ylabel('Time (sec)')
plt.title('Metadata Performance')
plt.legend((hdfs_rects[0], bfs_rects[0]), ('HDFS', 'BoomFS'), loc='upper right')
plt.ylim([0, 1200])
plt.savefig('metadata_throughput.pdf')
##
I see the following error using matplotlib 0.95.1:
Traceback (most recent call last):
 File "metadata_throughput.py", line 21, in <module>
 plt.savefig('metadata_throughput.pdf')
 File "/opt/local/lib/python2.5/site-packages/matplotlib/pyplot.py",
line 345, in savefig
 return fig.savefig(*args, **kwargs)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/figure.py",
line 990, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 1419, in print_figure
 **kwargs)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 1313, in print_pdf
 return pdf.print_pdf(*args, **kwargs)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
line 1883, in print_pdf
 self.figure.draw(renderer)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/figure.py",
line 772, in draw
 for a in self.axes: a.draw(renderer)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/axes.py",
line 1601, in draw
 a.draw(renderer)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/patches.py",
line 301, in draw
 renderer.draw_path(gc, tpath, affine, rgbFace)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
line 1248, in draw_path
 self.check_gc(gc, rgbFace)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
line 1203, in check_gc
 delta = self.gc.delta(gc)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
line 1813, in delta
 cmds.extend(cmd(self, *theirs))
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
line 1725, in hatch_cmd
 name = self.file.hatchPattern(lst)
 File "/opt/local/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
line 945, in hatchPattern
 return pattern[0]
AttributeError: Name instance has no attribute '__getitem__'
If I change the savefig() call to emit EPS or PNG instead, e.g:
plt.savefig('metadata_throughput.eps')
The program works fine, and I get the output I'd expect. Does anyone
have any suggestions about what's going wrong here?
Thanks in advance,
Neil

On Wed, Dec 17, 2008 at 1:19 PM, Ken Schutte <kts...@gm...> wrote:
> It might be nice if eventually there were extra styles, e.g. "-|>", "<|-|>"
> for single lines with solid arrowheads
This is now added in the trunk.
-JJ

John,
I updated api_chages.rst (but you'd better check my english). I also
made a few changes so that a warning is issued when deprecated
parameters are used in rc file. I deleted deprecated parameters in
lib/matplotlib/rcsetup.py and also from
lib/matplotlib/mpl-data/matplotlib.conf.template. I did my own test
and it worked well for me, and I hope it does not cause any problem.
Regards,
-JJ
On Fri, Dec 19, 2008 at 9:44 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Dec 19, 2008 at 8:36 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> The legend class has been reimplemented recently and the name of some
>> keyword arguments (and their meaning) has been changed. Those
>> parameters you're using are deprecated ones. It is supposed to show
>> you some warnings if deprecated parameters are used, so what you see
>> is a bug. I'll take a look. I also noticed that the documentaion of
>> the pylab.legend is outdated. Take a look at
>
> Jae-Joon,
>
> I don't think these changes ever made it into doc/api/api_changes.rst.
> Could you update that file in the branch, and I'll push it out the
> web site.
>
> Thanks,
> JDH
>

OK:
Downloaded latest (Friday, Dec 19: 1200 Pacific Time) egg and mpkg from 
sourceforge:
egg:
* cleared out all previous installs and cleaned out easy_install.pth file.
* easy_install matplotlib-0.98.5.2-py2.5.egg
Whoo hoo! all works great!
* cleared it all out again...
* Installed the mpkg
Whoo Hoo! another success!
One note on the mpkg -- it's called:
Matplotlib-0.98.5.2-py2.5-macosx10.5.mpkg
but it seems to work fine on 10.4 as well as 10.5 -- perhaps a re-naming 
is in order to save some confusion.
Mac OS-C 10.4.11 Dual G5 PPC - python.org Python 2.5.2
Thanks for everyone's work getting this put together.
-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...

Ramiro Simões Lopes wrote:
> Thanks, it works.
> But I also found out that I was setting figsize to a smaller size than 
> the plot was occupying thus it wasn't working. The anchor kwarg isn't 
> needed if the figure is big enough.
> 
> I still don't understand why the axes aspect ratio should depend on 
> figsize though.
> I mean, if I set figsize=(10,10) and plot everything, it works. But if I 
> set it to like (10,15) then the axes have spacing between them in the 
> vertical direction, even though I'm very specific about the coordinates.
> How can 0.01 mean one thing in the horizontal direction and other in the 
> vertical direction?
> 
> Ramiro
Ramiro,
(When corresponding on the list, please use "reply to all" so that 
everything stays on the list.)
First, the 0.01 is 0.01 times the figure width for the horizontal, and 
0.01 times the figure height for the vertical, so they are different 
physical dimensions if the figure aspect ratio is not 1:1. Second, 
setting the aspect='equal' tells mpl to *adjust* the axes box so that it 
 has a 1:1 aspect ratio *regardless* of the figure dimensions. It can 
only do this by adding space, either on the sides or top and bottom.
Eric
> 
> 
> 
> 2008年12月18日 Eric Firing <ef...@ha... <mailto:ef...@ha...>>
> 
> ramirodsl wrote:
> 
> Can someone explain to me how/why the figure normalized [0,1]
> coordinates
> depends on the figsize property? At least this is what it looks
> like to me.
> This affects axes placement and so far I haven't been able to do
> what I
> want.
> 
> I want to have square plots placed without spacing between them
> and with a
> little margin on the left and top. So I tried:
> 
> s=0.4
> axes([0.01, 0.99-s, s, s],aspect='equal')
> axes([0.01+s, 0.99-s, s, s],aspect='equal')
> axes([0.01, 0.99-2*s, s, s],aspect='equal')
> axes([0.01+s, 0.99-2*s, s, s],aspect='equal')
> 
> The vertical positioning works as I expected but the x
> positioning does not
> work. The axes have spacing between them - which means that 0.1
> represents a
> different size in x or in y - and I just can't understand that
> behavior.
> 
> 
> The problem is that you are giving conflicting instructions. Your
> axes command is initially saying to make the boxes with the given
> proportions of the figure, regardless of the dimensions or aspect
> ratio of that figure; but setting the aspect is overriding that by
> requiring the boxes to be square. You can still get the behavior
> you want, however, by adding an anchor kwarg to each axes call. To
> make sure the
> boxes cluster together, add anchor='SE' to the upper left axes,
> anchor='SW' to the upper right, and 'NE' and 'NW' to the lower left
> and right, respectively.
> 
> Eric
> 
> 
> Now if I add:
> figure(figsize=(5,5))
> it works
> 
> But this is not the solution I need because the real plot I'm
> trying to do
> is a 6x5 (6 axes per 5 axes, subplots if you mean) plot with
> horizontal
> spacing only between the 3rd and 4th axes. There is no way I
> could now the
> correct aspect ratio that I should set figsize to, to get it right.
> 
> How could I manage this?
> 
> Thank you
> 
> Ramiro
> 
> 
> 

On Fri, Dec 19, 2008 at 18:47, Ondrej Certik <on...@ce...> wrote:
> On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi <mo...@de...> wrote:
>> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
>> on uploading it Debian, together with John and Michael (and all dev
>> team), to have a feasable release.
>
> Ah, I didn't know you are on the mpl dev team as well. That's great.
Oh no no: I bother them for something, and they (to force me to
silence) release a fix :D
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi <mo...@de...> wrote:
> Hello Ondrej,
>
> On Fri, Dec 19, 2008 at 18:18, Ondrej Certik <on...@ce...> wrote:
>> we got this Debian bug:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
> ...
>> I tested that this applies to 0.98.3. Is this a bug?
>
> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
> on uploading it Debian, together with John and Michael (and all dev
> team), to have a feasable release.
Ah, I didn't know you are on the mpl dev team as well. That's great.
Ondrej

Hello Ondrej,
On Fri, Dec 19, 2008 at 18:18, Ondrej Certik <on...@ce...> wrote:
> we got this Debian bug:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
...
> I tested that this applies to 0.98.3. Is this a bug?
This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
on uploading it Debian, together with John and Michael (and all dev
team), to have a feasable release.
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi,
we got this Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
Citing:
"
the following python code creates a histogram with an x-axis range of
0.1 min to 0.3 max (based on the mins and maxes of the x rather than bin).
the bins should be used to size the axis since the user specified that
he wanted to see those specific bins (even though they are empty). note
that the 'range=' option would be a potential solution, but it is ignored
when bin is a sequence (presumably because the range would be chosen
based on bin's limits, but this isn't so).
 from pylab import *
 x = [0.18,0.22,0.19]
 bin = [0,0.1,0.2,0.3,0.4,0.5]
 hist(x,bin)
 show()
i believe that the x-axis ranges should instead be based on the mins and
maxes of bin when it is a sequence.
please forward this report upstream or let me know if you believe that it
belongs there.
thank you for your consideration
"
I tested that this applies to 0.98.3. Is this a bug?
Thanks,
Ondrej

On Fri, Dec 19, 2008 at 8:36 AM, Jae-Joon Lee <lee...@gm...> wrote:
> The legend class has been reimplemented recently and the name of some
> keyword arguments (and their meaning) has been changed. Those
> parameters you're using are deprecated ones. It is supposed to show
> you some warnings if deprecated parameters are used, so what you see
> is a bug. I'll take a look. I also noticed that the documentaion of
> the pylab.legend is outdated. Take a look at
Jae-Joon,
I don't think these changes ever made it into doc/api/api_changes.rst.
 Could you update that file in the branch, and I'll push it out the
web site.
Thanks,
JDH