matplotlib-users Mailing List for matplotlib (Page 7)

Maybe I'm missing it... but how do I change the color of the tick marks? 
(the actual marks, not the labels).
I would like gray tick marks, not black... 
Thank you... Russ
 http://www.nabble.com/file/p17297888/graph.jpg 
-- 
View this message in context: http://www.nabble.com/Tick-color-tp17297888p17297888.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Sat, May 17, 2008 at 3:49 PM, Rodney Haynie <RH...@co...> wrote:
> "C:\Python25\lib\site-packages\matplotlib-0.91.2.0001-py2.5-win32.egg\matplo
> tlib\backends\backend_agg.py", line 397, in print_png
> self.get_renderer()._renderer.write_png(str(filename),
> self.figure.dpi.get())
> RuntimeError: Could not open file <open file '<stdout>', mode 'w' at
> 0x00A0F068>
I believe this has been fixed on the maintenance branch (which will
become 0.91.3 shortly after the next release). You can get a svn
checkout of this branch at
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint
 mpl91
Michael, I notice in the code we have:
 if type(filename_or_obj) in (str, unicode):
 filename_or_obj = open(filename_or_obj, 'w')
is there any reason not to use cbook.is_string_like here, which should
be more general?
Thanks,
JDH

Having some issues getting a png to flow out to a web page. I am trying to
use savefig( sys.stdout ), but I am getting an error. Well at least I can
show the error when I run the script from a command prompt.
I took most of the example from the matplotlib pdf file. I added a couple
print statements in order to get more feedback from the web server.
When run from the command prompt in Windows, My output looks like this:
hello world<br>
This is the second line.<br>
Traceback (most recent call last):
 File "C:\www\app\webroot\cgi-bin\stdout.py", line 12, in <module>
 savefig( sys.stdout )
 File
"C:\Python25\lib\site-packages\matplotlib-0.91.2.0001-py2.5-win32.egg\matplo
tlib\pyplot.py", line 269, in savefig
 return fig.savefig(*args, **kwargs)
 File
"C:\Python25\lib\site-packages\matplotlib-0.91.2.0001-py2.5-win32.egg\matplo
tlib\figure.py", line 782, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"C:\Python25\lib\site-packages\matplotlib-0.91.2.0001-py2.5-win32.egg\matplo
tlib\backend_bases.py", line 1195, in print_figure
 **kwargs)
 File
"C:\Python25\lib\site-packages\matplotlib-0.91.2.0001-py2.5-win32.egg\matplo
tlib\backends\backend_agg.py", line 397, in print_png
 self.get_renderer()._renderer.write_png(str(filename),
self.figure.dpi.get())
RuntimeError: Could not open file <open file '<stdout>', mode 'w' at
0x00A0F068>
---
Here is some version info:
Windows XP Pro
Python 2.5.2
matplotlib-0.91.2.0001-py2.5-win32.egg
numpy-1.0.4.0002-py2.5-win32.egg
My entire script is listed below:
#!c:/Python25/python.exe -u
print
print "hello world<br>"
import sys
import matplotlib
# this is not supported across all backends , as of matplotlib -0.63
matplotlib.use('Agg')
from pylab import *
print "This is the second line.<br>"
plot ([1 ,2 ,3])
savefig( sys.stdout )
---
When I put this script in the cgi directory and refer to it in my URL, the
response only shows Hello World. The "This is the second line." never
displays. Seems that as soon as I import matplotlib I am not able to print
to stdout.
Any suggestions would be appreciated.
-Rodney

Thank you. I committed the fix, r5170.
Eric
Jörgen Stenarson wrote:
> John Hunter skrev:
>> On Fri, May 16, 2008 at 1:46 PM, Jörgen Stenarson
>> <jor...@bo...> wrote:
>>> Hi,
>>>
>>> with current svn (r5149) I get currupt png files when saving using
>>> pylab.savefig. I'm using the TkAgg backend with no changes to the 
>>> default
>>> matplotlibrc. It looks like the problem occurs first with r5026. I have
>>> attached pngs generated using the same script for r5025, r5026, and 
>>> r5149.
>>
>> This appears to be the relevant changeset :
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/src/_backend_agg.cpp?r1=4929&r2=5026 
>>
>>
>> you have some time to poke through the changes, perhaps you can find
>> out what is wrong for your platform. We are a bit short on win32
>> developers who have access to svn right now.
>>
> 
> It turned out it was easier than some obscure windows related c++ bug. 
> The changes in backend_agg.py creates a file handle in text mode and not 
> binary mode which results in corrupted files on windows. The attached 
> patch fixed the problem for me.
> 
> /Jörgen
> 
> 
> ------------------------------------------------------------------------
> 
> Index: lib/matplotlib/backends/backend_agg.py
> ===================================================================
> --- lib/matplotlib/backends/backend_agg.py	(revision 5169)
> +++ lib/matplotlib/backends/backend_agg.py	(working copy)
> @@ -290,7 +290,7 @@
> original_dpi = renderer.dpi
> renderer.dpi = self.figure.dpi
> if type(filename_or_obj) in (str, unicode):
> - filename_or_obj = open(filename_or_obj, 'w')
> + filename_or_obj = open(filename_or_obj, 'wb')
> renderer._renderer.write_rgba(filename_or_obj)
> renderer.dpi = original_dpi
> print_rgba = print_raw
> @@ -301,6 +301,6 @@
> original_dpi = renderer.dpi
> renderer.dpi = self.figure.dpi
> if type(filename_or_obj) in (str, unicode):
> - filename_or_obj = open(filename_or_obj, 'w')
> + filename_or_obj = open(filename_or_obj, 'wb')
> self.get_renderer()._renderer.write_png(filename_or_obj, self.figure.dpi)
> renderer.dpi = original_dpi
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

John Hunter skrev:
> On Fri, May 16, 2008 at 1:46 PM, Jörgen Stenarson
> <jor...@bo...> wrote:
>> Hi,
>>
>> with current svn (r5149) I get currupt png files when saving using
>> pylab.savefig. I'm using the TkAgg backend with no changes to the default
>> matplotlibrc. It looks like the problem occurs first with r5026. I have
>> attached pngs generated using the same script for r5025, r5026, and r5149.
> 
> This appears to be the relevant changeset :
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/src/_backend_agg.cpp?r1=4929&r2=5026
> 
> you have some time to poke through the changes, perhaps you can find
> out what is wrong for your platform. We are a bit short on win32
> developers who have access to svn right now.
> 
It turned out it was easier than some obscure windows related c++ bug. 
The changes in backend_agg.py creates a file handle in text mode and not 
binary mode which results in corrupted files on windows. The attached 
patch fixed the problem for me.
/Jörgen

On Fri, May 16, 2008 at 1:46 PM, Jörgen Stenarson
<jor...@bo...> wrote:
> Hi,
>
> with current svn (r5149) I get currupt png files when saving using
> pylab.savefig. I'm using the TkAgg backend with no changes to the default
> matplotlibrc. It looks like the problem occurs first with r5026. I have
> attached pngs generated using the same script for r5025, r5026, and r5149.
This appears to be the relevant changeset :
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/src/_backend_agg.cpp?r1=4929&r2=5026
 you have some time to poke through the changes, perhaps you can find
out what is wrong for your platform. We are a bit short on win32
developers who have access to svn right now.
JDH

Bryan Fodness wrote:
> i didn't have 0.92.1, i have 0.91.2
Right, we were both transposing digits.
> 
> [bryan@ ~]$ python 
> Python 2.5.2 (r252:60911, May 13 2008, 22:14:05) 
> [GCC 4.1.2 20070502 (Red Hat 4.1.2-12)] on linux2 
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import matplotlib 
> >>> matplotlib.__version__ 
> '0.91.2' 
> >>> import numpy 
> >>> numpy.__version__ 
> '1.0.4' 
> >>> 
> 
> [bryan@ ~]$ locate pylab.py 
> /usr/lib/python2.5/site-packages/pylab.py 
> /usr/lib/python2.5/site-packages/pylab.pyc 
> /usr/lib/python2.5/site-packages/pylab.pyo 
> /usr/lib/python2.5/site-packages/matplotlib/pylab.py 
> /usr/lib/python2.5/site-packages/matplotlib/pylab.pyc 
> /usr/lib/python2.5/site-packages/matplotlib/pylab.pyo 
> /usr/local/lib/python2.5/site-packages/pylab.py 
> /usr/local/lib/python2.5/site-packages/pylab.pyc 
> /usr/local/lib/python2.5/site-packages/matplotlib/pylab.py 
> /usr/local/lib/python2.5/site-packages/matplotlib/pylab.pyc
> [bryan@~]$ 
OK, so you do have two versions installed, and I would still bet that 
modules from the older version are getting found when you run your 
script, if not when you do the test above.
You installed 0.91.2 from source in /usr/local/lib/*, correct? Then use 
your package manager to delete the older version (in /usr/lib/*), and 
try again.
Eric
> 
> On Fri, May 16, 2008 at 1:35 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> Bryan,
> 
> It appears that you are not using the mpl version you think you are.
> When I look at colors.py for 0.92.1, it doesn't match your error
> message.
> 
> What do you get when you do, from a python prompt:
> 
> import matplotlib
> print matplotlib.__version__
> 
> You might try using "locate pylab.py" to find out where the various
> versions are.
> 
> Eric
> 
> Bryan Fodness wrote:
> 
> I have updated to matplotlib 0.92.1 and numpy 1.0.4 and still
> receive an error.
> /space/work/Bryan$ ./Check_0.1.py <http://check_0.1.py/>
> <http://Check_0.1.py <http://check_0.1.py/>>
> 
> Traceback (most recent call last):
> File "./Check_0.1.py <http://check_0.1.py/>
> <http://Check_0.1.py <http://check_0.1.py/>>", line 344, in
> <module>
> 
> savefig(outfile)
> File "/usr/lib/python2.5/site-packages/matplotlib/pylab.py",
> line 796, in savefig
> return fig.savefig(*args, **kwargs)
> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py",
> line 727, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> line 456, in print_figure
> self.draw()
> File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> line 392, in draw
> self.figure.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py",
> line 569, in draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/axes.py",
> line 1155, in draw
> a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/patches.py",
> line 209, in draw
> else: rgbFace = colorConverter.to_rgb(self._facecolor)
> File "/usr/lib/python2.5/site-packages/matplotlib/colors.py",
> line 429, in to_rgb
> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' %
> (str(arg), exc))
> ValueError: to_rgb: Invalid rgb arg "None"
> invalid literal for float(): None
> Does anyone have an idea? It works in Windows.
> On Fri, May 9, 2008 at 5:18 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...> <mailto:ef...@ha...
> <mailto:ef...@ha...>>> wrote:
> 
> Bryan Fodness wrote:
> 
> i have used this command on windows vista with no problem.
> 
> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
> 
> but when i run on fedora 8, i receive the following.
> 
> [...]
> 
> File
> "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line
> 429, in tob
> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' %
> (str(arg), exc))
> ValueError: to_rgb: Invalid rgb arg "None"
> invalid literal for float(): None
> could someone tell me if i am missing something?
> 
> 
> Sounds like you have an older mpl version on the Fedora
> machine than
> on the Win box.
> 
> Eric
> 
> 
> 
> 
> -- 
> "The game of science can accurately be described as a
> never-ending insult to human intelligence." - João Magueijo
> 
> 
> 
> 
> 
> -- 
> "The game of science can accurately be described as a never-ending 
> insult to human intelligence." - João Magueijo
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Leif Oppermann wrote:
> Can someone tell me how to do kriging in Matplotlib?
> 
> I have tried the contourf() function with two bivariate_normal() objects 
> as input which produces similar looking results to what I want to 
> archive. My data however is geo-referenced and contains > 100000 
> samples. Generating 100000 objects doesn't sound like a good idea to me. 
> I searched the docs before posting, but the term "kriging" doesn't even 
> show in the docs.
> 
> Maybe I missed something obvious? Any hint appreciated.
There is no kriging implementation in matplotlib. Kriging is a special case of 
Gaussian processes, though, so the RandomRealizations package or my own gp 
package might be of use to you. You will have to do some reading to translate 
the entities you are familiar with (variograms, etc.) to the entities used in 
Gaussian processes (covariance functions, etc.).
 http://code.google.com/p/random-realizations/
 http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/gp/
Anand has been doing more work on RandomRealizations than I have on gp, so try 
it first.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Thanks for your help!
I was forcing it to look in an old location with,
 #!/usr/bin/python
as my first line.
On Fri, May 16, 2008 at 1:44 PM, Bryan Fodness <bry...@gm...>
wrote:
> i didn't have 0.92.1, i have 0.91.2
>
> [bryan@ ~]$ python
> Python 2.5.2 (r252:60911, May 13 2008, 22:14:05)
> [GCC 4.1.2 20070502 (Red Hat 4.1.2-12)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import matplotlib
> >>> matplotlib.__version__
> '0.91.2'
> >>> import numpy
> >>> numpy.__version__
> '1.0.4'
> >>>
>
> [bryan@ ~]$ locate pylab.py
> /usr/lib/python2.5/site-packages/pylab.py
> /usr/lib/python2.5/site-packages/pylab.pyc
> /usr/lib/python2.5/site-packages/pylab.pyo
> /usr/lib/python2.5/site-packages/matplotlib/pylab.py
> /usr/lib/python2.5/site-packages/matplotlib/pylab.pyc
> /usr/lib/python2.5/site-packages/matplotlib/pylab.pyo
> /usr/local/lib/python2.5/site-packages/pylab.py
> /usr/local/lib/python2.5/site-packages/pylab.pyc
> /usr/local/lib/python2.5/site-packages/matplotlib/pylab.py
> /usr/local/lib/python2.5/site-packages/matplotlib/pylab.pyc
> [bryan@~]$
>
> On Fri, May 16, 2008 at 1:35 PM, Eric Firing <ef...@ha...> wrote:
>
>> Bryan,
>>
>> It appears that you are not using the mpl version you think you are. When
>> I look at colors.py for 0.92.1, it doesn't match your error message.
>>
>> What do you get when you do, from a python prompt:
>>
>> import matplotlib
>> print matplotlib.__version__
>>
>> You might try using "locate pylab.py" to find out where the various
>> versions are.
>>
>> Eric
>>
>> Bryan Fodness wrote:
>>
>>> I have updated to matplotlib 0.92.1 and numpy 1.0.4 and still receive an
>>> error.
>>> /space/work/Bryan$ ./Check_0.1.py <http://check_0.1.py/> <
>>> http://Check_0.1.py <http://check_0.1.py/>>
>>> Traceback (most recent call last):
>>> File "./Check_0.1.py <http://check_0.1.py/> <http://Check_0.1.py<http://check_0.1.py/>>",
>>> line 344, in <module>
>>> savefig(outfile)
>>> File "/usr/lib/python2.5/site-packages/matplotlib/pylab.py", line 796,
>>> in savefig
>>> return fig.savefig(*args, **kwargs)
>>> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 727,
>>> in savefig
>>> self.canvas.print_figure(*args, **kwargs)
>>> File
>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line
>>> 456, in print_figure
>>> self.draw()
>>> File
>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line
>>> 392, in draw
>>> self.figure.draw(renderer)
>>> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 569,
>>> in draw
>>> for a in self.axes: a.draw(renderer)
>>> File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1155,
>>> in draw
>>> a.draw(renderer)
>>> File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 209,
>>> in draw
>>> else: rgbFace = colorConverter.to_rgb(self._facecolor)
>>> File "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line 429,
>>> in to_rgb
>>> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
>>> ValueError: to_rgb: Invalid rgb arg "None"
>>> invalid literal for float(): None
>>> Does anyone have an idea? It works in Windows.
>>> On Fri, May 9, 2008 at 5:18 PM, Eric Firing <ef...@ha...<mailto:
>>> ef...@ha...>> wrote:
>>>
>>> Bryan Fodness wrote:
>>>
>>> i have used this command on windows vista with no problem.
>>>
>>> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
>>>
>>> but when i run on fedora 8, i receive the following.
>>>
>>> [...]
>>>
>>> File
>>> "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line
>>> 429, in tob
>>> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' %
>>> (str(arg), exc))
>>> ValueError: to_rgb: Invalid rgb arg "None"
>>> invalid literal for float(): None
>>> could someone tell me if i am missing something?
>>>
>>>
>>> Sounds like you have an older mpl version on the Fedora machine than
>>> on the Win box.
>>>
>>> Eric
>>>
>>>
>>>
>>>
>>> --
>>> "The game of science can accurately be described as a never-ending insult
>>> to human intelligence." - João Magueijo
>>>
>>
>>
>
>
> --
> "The game of science can accurately be described as a never-ending insult
> to human intelligence." - João Magueijo
>
-- 
"The game of science can accurately be described as a never-ending insult to
human intelligence." - João Magueijo

Hi,
with current svn (r5149) I get currupt png files when saving using 
pylab.savefig. I'm using the TkAgg backend with no changes to the 
default matplotlibrc. It looks like the problem occurs first with r5026. 
I have attached pngs generated using the same script for r5025, r5026, 
and r5149.
I compile matplotlib using mingw32 and the win32_static precompiled 
dependencies.
my configuration:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit 
(Intel)]
numpy 1.1.0.dev5176
matplotlib 0.98pre 5149
scipy 0.7.0.dev4352
IPython 0.8.3.bzr.r96
pyreadline 1.6.svn $Revision: 2879 $
the plot script:
import numpy, pylab, matplotlib
from numpy import sin, arange, pi
x=arange(0, 2*pi, 0.1)
pylab.plot(x, sin(x))
pylab.savefig("testplot-rev.png")
/Jörgen

i didn't have 0.92.1, i have 0.91.2
[bryan@ ~]$ python
Python 2.5.2 (r252:60911, May 13 2008, 22:14:05)
[GCC 4.1.2 20070502 (Red Hat 4.1.2-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.__version__
'0.91.2'
>>> import numpy
>>> numpy.__version__
'1.0.4'
>>>
[bryan@ ~]$ locate pylab.py
/usr/lib/python2.5/site-packages/pylab.py
/usr/lib/python2.5/site-packages/pylab.pyc
/usr/lib/python2.5/site-packages/pylab.pyo
/usr/lib/python2.5/site-packages/matplotlib/pylab.py
/usr/lib/python2.5/site-packages/matplotlib/pylab.pyc
/usr/lib/python2.5/site-packages/matplotlib/pylab.pyo
/usr/local/lib/python2.5/site-packages/pylab.py
/usr/local/lib/python2.5/site-packages/pylab.pyc
/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py
/usr/local/lib/python2.5/site-packages/matplotlib/pylab.pyc
[bryan@~]$
On Fri, May 16, 2008 at 1:35 PM, Eric Firing <ef...@ha...> wrote:
> Bryan,
>
> It appears that you are not using the mpl version you think you are. When I
> look at colors.py for 0.92.1, it doesn't match your error message.
>
> What do you get when you do, from a python prompt:
>
> import matplotlib
> print matplotlib.__version__
>
> You might try using "locate pylab.py" to find out where the various
> versions are.
>
> Eric
>
> Bryan Fodness wrote:
>
>> I have updated to matplotlib 0.92.1 and numpy 1.0.4 and still receive an
>> error.
>> /space/work/Bryan$ ./Check_0.1.py <http://check_0.1.py/> <
>> http://Check_0.1.py <http://check_0.1.py/>>
>> Traceback (most recent call last):
>> File "./Check_0.1.py <http://check_0.1.py/> <http://Check_0.1.py<http://check_0.1.py/>>",
>> line 344, in <module>
>> savefig(outfile)
>> File "/usr/lib/python2.5/site-packages/matplotlib/pylab.py", line 796, in
>> savefig
>> return fig.savefig(*args, **kwargs)
>> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 727,
>> in savefig
>> self.canvas.print_figure(*args, **kwargs)
>> File
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line
>> 456, in print_figure
>> self.draw()
>> File
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line
>> 392, in draw
>> self.figure.draw(renderer)
>> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 569,
>> in draw
>> for a in self.axes: a.draw(renderer)
>> File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1155, in
>> draw
>> a.draw(renderer)
>> File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 209,
>> in draw
>> else: rgbFace = colorConverter.to_rgb(self._facecolor)
>> File "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line 429,
>> in to_rgb
>> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
>> ValueError: to_rgb: Invalid rgb arg "None"
>> invalid literal for float(): None
>> Does anyone have an idea? It works in Windows.
>> On Fri, May 9, 2008 at 5:18 PM, Eric Firing <ef...@ha... <mailto:
>> ef...@ha...>> wrote:
>>
>> Bryan Fodness wrote:
>>
>> i have used this command on windows vista with no problem.
>>
>> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
>>
>> but when i run on fedora 8, i receive the following.
>>
>> [...]
>>
>> File
>> "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line
>> 429, in tob
>> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' %
>> (str(arg), exc))
>> ValueError: to_rgb: Invalid rgb arg "None"
>> invalid literal for float(): None
>> could someone tell me if i am missing something?
>>
>>
>> Sounds like you have an older mpl version on the Fedora machine than
>> on the Win box.
>>
>> Eric
>>
>>
>>
>>
>> --
>> "The game of science can accurately be described as a never-ending insult
>> to human intelligence." - João Magueijo
>>
>
>
-- 
"The game of science can accurately be described as a never-ending insult to
human intelligence." - João Magueijo

Bryan,
It appears that you are not using the mpl version you think you are. 
When I look at colors.py for 0.92.1, it doesn't match your error message.
What do you get when you do, from a python prompt:
import matplotlib
print matplotlib.__version__
You might try using "locate pylab.py" to find out where the various 
versions are.
Eric
Bryan Fodness wrote:
> I have updated to matplotlib 0.92.1 and numpy 1.0.4 and still receive 
> an error.
> /space/work/Bryan$ ./Check_0.1.py <http://Check_0.1.py>
> Traceback (most recent call last):
> File "./Check_0.1.py <http://Check_0.1.py>", line 344, in <module>
> savefig(outfile)
> File "/usr/lib/python2.5/site-packages/matplotlib/pylab.py", line 796, 
> in savefig
> return fig.savefig(*args, **kwargs)
> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
> 727, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 456, in print_figure
> self.draw()
> File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 392, in draw
> self.figure.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
> 569, in draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1155, 
> in draw
> a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
> 209, in draw
> else: rgbFace = colorConverter.to_rgb(self._facecolor)
> File "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line 
> 429, in to_rgb
> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
> ValueError: to_rgb: Invalid rgb arg "None"
> invalid literal for float(): None
> Does anyone have an idea? It works in Windows.
> 
> On Fri, May 9, 2008 at 5:18 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> Bryan Fodness wrote:
> 
> i have used this command on windows vista with no problem.
> 
> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
> 
> but when i run on fedora 8, i receive the following.
> 
> [...]
> 
> File
> "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line
> 429, in tob
> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' %
> (str(arg), exc))
> ValueError: to_rgb: Invalid rgb arg "None"
> invalid literal for float(): None
> could someone tell me if i am missing something?
> 
> 
> 
> Sounds like you have an older mpl version on the Fedora machine than
> on the Win box.
> 
> Eric
> 
> 
> 
> 
> -- 
> "The game of science can accurately be described as a never-ending 
> insult to human intelligence." - João Magueijo

Can someone tell me how to do kriging in Matplotlib?
I have tried the contourf() function with two bivariate_normal() objects 
as input which produces similar looking results to what I want to 
archive. My data however is geo-referenced and contains > 100000 
samples. Generating 100000 objects doesn't sound like a good idea to me. 
I searched the docs before posting, but the term "kriging" doesn't even 
show in the docs.
Maybe I missed something obvious? Any hint appreciated.
Thanks,
 Leif
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Hi,
Given a pcolor figure (about 30 x 30 values) without axis.
We can see all cases like a chess board.
 From two string lists of 30 elements, is it be possible to add a name 
to all columns and lines.
These name would be located at the bottom (for column) and on the left 
(for line) and in the midle of each column and line.
In fact, the label would be words like date but with explicit list of 
string and not with locator.
Thanks a lot,
Cyril.

I have updated to matplotlib 0.92.1 and numpy 1.0.4 and still receive
an error.
/space/work/Bryan$ ./Check_0.1.py
Traceback (most recent call last):
 File "./Check_0.1.py", line 344, in <module>
 savefig(outfile)
 File "/usr/lib/python2.5/site-packages/matplotlib/pylab.py", line 796, in
savefig
 return fig.savefig(*args, **kwargs)
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 727, in
savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line
456, in print_figure
 self.draw()
 File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line
392, in draw
 self.figure.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 569, in
draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1155, in
draw
 a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 209,
in draw
 else: rgbFace = colorConverter.to_rgb(self._facecolor)
 File "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line 429, in
to_rgb
 raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
ValueError: to_rgb: Invalid rgb arg "None"
invalid literal for float(): None
Does anyone have an idea? It works in Windows.
On Fri, May 9, 2008 at 5:18 PM, Eric Firing <ef...@ha...> wrote:
> Bryan Fodness wrote:
>
>> i have used this command on windows vista with no problem.
>>
>> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
>>
>> but when i run on fedora 8, i receive the following.
>>
> [...]
>
>> File "/usr/lib/python2.5/site-packages/matplotlib/colors.py", line
>> 429, in tob
>> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg),
>> exc))
>> ValueError: to_rgb: Invalid rgb arg "None"
>> invalid literal for float(): None
>> could someone tell me if i am missing something?
>>
>>
>
> Sounds like you have an older mpl version on the Fedora machine than on the
> Win box.
>
> Eric
>
-- 
"The game of science can accurately be described as a never-ending insult to
human intelligence." - João Magueijo

On Thu, May 15, 2008 at 01:56:19PM -0500, John Hunter wrote:
> On Thu, May 15, 2008 at 3:41 AM, Friedrich Hagedorn <fri...@gm...> wrote:
> > On Thu, May 15, 2008 at 10:20:23AM +0200, Friedrich Hagedorn wrote:
> >> Hello,
> >>
> >> I think the following is'nt right:
> >>
> >> In [1]: plot([1,2,3])
> >> Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
> >>
> >> In [2]: ylim(-4,4)
> >> Out[2]: (-4, 4)
> >>
> >> In [3]: axhline()
> >> Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
[...]
> For example, consider this case
> 
> plot([1,2,3])
> ylim(-4,4)
> axhline(20)
> 
> What we want is to autoscale only if autoscale_on=True *and* the hline
> is outside the current bounds. Something like:
> 
> ymin, ymax = self.get_ylim()
> if ymax<ymin: ymin, ymax = ymax, ymin
> scaley = (y<ymin) or (y>ymax)
> 
> trans = mtransforms.blended_transform_factory(
> self.transAxes, self.transData)
> l, = self.plot([xmin,xmax], [y,y], transform=trans,
> scalex=False, scaley=scaley, **kwargs)
> 
> I just committed this to svn in r5141 so give it a test drive and let
> me know what you think.
You are right. This patch works fine for me, thanks.
> There is an unrelated problem with the autoscaler which is that in the example
> 
> plot([1,2,3])
> axhline(20)
> 
> it sets ymax to 20 making the hline invisible. 
But there is no problem with
 axhline(20.2)
Thats why the autoscale sets the outer ticks to the boundaries.
> We should probably
> force the ylimits to be strictly outside the data limits in some cases
> when autoscaling.
I think this would be better then the current (undefined) behaviour (sometimes
the datalines touches the boundaries and sometimes not).
For my own stuff I have used 
 gca().set_ylim(ax.dataLim.intervaly*1.2)
 
for a 'autoscale' replacement.
By,
 Friedrich

On Thu, May 15, 2008 at 3:41 AM, Friedrich Hagedorn <fri...@gm...> wrote:
> On Thu, May 15, 2008 at 10:20:23AM +0200, Friedrich Hagedorn wrote:
>> Hello,
>>
>> I think the following is'nt right:
>>
>> In [1]: plot([1,2,3])
>> Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
>>
>> In [2]: ylim(-4,4)
>> Out[2]: (-4, 4)
>>
>> In [3]: axhline()
>> Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
While I agree the behavior here is not optimal, I don't think the fix
is right. axhline already tells the axes not to autoscale in the x
direction, as it should
l, = self.plot([xmin,xmax], [y,y], transform=trans, scalex=False, **kwargs)
so I don't think automatically forcing the autoscale off entirely for
x and y as in your patch is what we want in general. For example,
consider this case
plot([1,2,3])
ylim(-4,4)
axhline(20)
What we want is to autoscale only if autoscale_on=True *and* the hline
is outside the current bounds. Something like:
 ymin, ymax = self.get_ylim()
 if ymax<ymin: ymin, ymax = ymax, ymin
 scaley = (y<ymin) or (y>ymax)
 trans = mtransforms.blended_transform_factory(
 self.transAxes, self.transData)
 l, = self.plot([xmin,xmax], [y,y], transform=trans,
scalex=False, scaley=scaley, **kwargs)
I just committed this to svn in r5141 so give it a test drive and let
me know what you think.
There is an unrelated problem with the autoscaler which is that in the example
plot([1,2,3])
axhline(20)
it sets ymax to 20 making the hline invisible. We should probably
force the ylimits to be strictly outside the data limits in some cases
when autoscaling.
JDH

Eric Firing wrote:
> Michael Droettboom wrote:
>> Yes, it looks like if it were an "unsigned int", we would have been 
>> okay. That looks like (essentially) what your patch does, but in a 
>> C++ idiom. I'll submit your patch and put a note out to the Windows 
>> guys to help test it. There's a good chance that if it compiles at 
>> all, it should work.
>
> Mike,
>
> If you understand what the patch does, and if you know how to do it in 
> a C idiom (or C++ for that matter) that is readable and that *will* 
> compile and run, then I would suggest that you modify the patch 
> accordingly instead of waiting to see if it *does* compile on whatever 
> compiler versions the Windows people happen to have right now.
It does compile and run on gcc-3.4 and gcc-4.2 on Linux, and solves 
Matle's crash (which I was never able to reproduce myself), so I 
committed the patch (with only cosmetic changes) to SVN. It just needs 
to be verified under Visual Studio, which I don't personally have.
Plus the whole Tcl thing where it encodes the pointer as a string of 
digits and then converts that back to an unsigned int gives me the 
heebie-jeebies, but I think we're stuck with that, for reasonable values 
of "stuck".
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

qEric Firing wrote:
> Michael Droettboom wrote:
>> Yes, it looks like if it were an "unsigned int", we would have been 
>> okay. That looks like (essentially) what your patch does, but in a 
>> C++ idiom. I'll submit your patch and put a note out to the Windows 
>> guys to help test it. There's a good chance that if it compiles at 
>> all, it should work.
>
> Looks like the C idiom would almost have to use
> something like sscanf(argv[2], "%lu", tmpulong).
That is a reasonable alternative.
> Is it bad form to use this in C++?
> Is *anything* actually standardized in C++?
The stringstream class used is in the C++ standard library. My concern 
is only based on Visual Studio not always adhering to it. In this case, 
it's a pretty safe bet it does -- it's a very core and long-standing 
piece of functionality.
> How does one know whether something like stringstream is safe to 
> use? The "ask someone to try it" approach is not very reassuring.
Barring more obvious documentation from Visual Studio (which may be 
mostly ignorance on my part) the only sure way to know is to try it. 
But it is in the specification and mentioned in Stroustrup, "C++: The 
Programming Language".
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Yes, it looks like if it were an "unsigned int", we would have been 
> okay. That looks like (essentially) what your patch does, but in a C++ 
> idiom. I'll submit your patch and put a note out to the Windows guys to 
> help test it. There's a good chance that if it compiles at all, it 
> should work.
Looks like the C idiom would almost have to use
something like sscanf(argv[2], "%lu", tmpulong).
Is it bad form to use this in C++?
Is *anything* actually standardized in C++? How does one know whether 
something like stringstream is safe to use? The "ask someone to try it" 
approach is not very reassuring.
Eric

Michael Droettboom wrote:
> Yes, it looks like if it were an "unsigned int", we would have been 
> okay. That looks like (essentially) what your patch does, but in a C++ 
> idiom. I'll submit your patch and put a note out to the Windows guys to 
> help test it. There's a good chance that if it compiles at all, it 
> should work.
Mike,
If you understand what the patch does, and if you know how to do it in a 
C idiom (or C++ for that matter) that is readable and that *will* 
compile and run, then I would suggest that you modify the patch 
accordingly instead of waiting to see if it *does* compile on whatever 
 compiler versions the Windows people happen to have right now.
Eric

On Thu, May 15, 2008 at 8:29 AM, Matthias Michler
<Mat...@gm...> wrote:
> Hello Jon,
>
> maybe I don't undestand correctly, but try to use more space left of the axes
> to avoid the disappering of the ylabel like:
> ax1 = fig.add_axes([0.3, 0.7, 0.6, 0.2])
> instead of
> ax1 = fig.add_axes([0.1, 0.7, 0.8, 0.2]) .
And if you are using subplots, you can move the left over a bit:
fig.subplots_adjust(left=0.2)

On Thu, May 15, 2008 at 9:31 AM, Jon Choy <jon...@gm...> wrote:
> Can someone tell me how to position the title? When I do a multiple
> plots, the title ends up in my top plot. I position the plot locations
> using the following:
>
> ax1 =fig.add_axes([0.2, 0.8, 0.65, 0.05], **axprops)
> ax2=fig.add_axes([0.2,0.75,0.65,0.05],**axprops)
>
> No matter where I position these axes, the title shows up right in the
> middle of the upper most plot. I'd like to put the title above the top
> most plot. Another option maybe to title the entire window. I'd like
> to know how to do that as well.
Use figure text:
figtitle = 'This is a somewhat long figure title'
t = fig.text(0.5, 0.95, figtitle,
 horizontalalignment='center',
 fontsize=16)

Can someone tell me how to position the title? When I do a multiple
plots, the title ends up in my top plot. I position the plot locations
using the following:
ax1 =fig.add_axes([0.2, 0.8, 0.65, 0.05], **axprops)
ax2=fig.add_axes([0.2,0.75,0.65,0.05],**axprops)
No matter where I position these axes, the title shows up right in the
middle of the upper most plot. I'd like to put the title above the top
most plot. Another option maybe to title the entire window. I'd like
to know how to do that as well.
 Jon

Hello Jon,
maybe I don't undestand correctly, but try to use more space left of the axes 
to avoid the disappering of the ylabel like:
ax1 = fig.add_axes([0.3, 0.7, 0.6, 0.2]) 
instead of
ax1 = fig.add_axes([0.1, 0.7, 0.8, 0.2]) .
That should be a solution, if you have not too different (considering their 
length) ylabels.
regards Matthias
PS: By the way, it might be useful to you to change the figure size with the 
keyword argument figsize of figure ( like fig=figure(figsize=(12, 6)) ).
On Thursday 15 May 2008 15:10:47 Jon Choy wrote:
> Yes, something I forgot to add is that I tried to resize the window
> and a couple more characters would show; but not the entire string.
> I'm trying to do multiple plots. Below is a signal named
> "pesm_gsm_prime" which is a good example of a signal with lots of
> characters. Unfortunately, I would like to preserve the name if
> possible and adjust the graphing frame if possible.
>
>
> Jon
>
>
>
> t = signals[signal][0]
> s1=signals[signal][1]
>
> fig = figure()
> yprops = dict(rotation=0,
> 	horizontalalignment='right',
> 	verticalalignment='center',
> 	clip_on = False,
> 	fontname='courier')
> axprops = dict(yticks=[])
> ax1 =fig.add_axes([0.1, 0.7, 0.8, 0.2], **axprops)
> ax1.plot(t, s1)
> ax1.axis([0,10000,-0.1,1.1])
> ax1.set_ylabel(signal, **yprops)
>
> axprops['sharex']=ax1
> axprops['sharey']=ax1
> # force x axes to remain in register, even with toolbar navigation
>
> signal = "pesm_gsm_prime"
> signals[signal]=[],[]
> for line in filedata:
> loadValueChange(signals,signal,line)
> t = signals[signal][0]
> s2=signals[signal][1]
>
> ax2=fig.add_axes([0.1,0.5,0.8,0.2],**axprops)
> ax2.plot(t,s2)
> ax2.axis([0,10000,-0.1,1.1])
> ax2.set_ylabel(signal,**yprops)
>
>
> for ax in ax1,ax2:
> setp(ax.get_xticklabels(),visible=False)
>
> #show()
> savefig('testplot.png')
>
>
> On Thu, May 15, 2008 at 2:35 AM, Matthias Michler wrote:
> > Hi Jon,
> >
> > On Thursday 15 May 2008 03:17:29 Jon Choy wrote:
> >> I maybe asking a dumb question, forgive me I'm a novice. I try to add
> >> a ylabel and the left portion of the signal name is cut off when it is
> >> plotted. I can't seem to find the option for displaying the whole
> >> signal. Or do I need to resize the plotting window?
> >
> > I think resizing the window is a good first attempt to see, if there is
> > everything written, but not shown to you.
> > Is your ylabel a very long string? Could you provide a small stand-alone
> > example of your problem, please?