matplotlib-users Mailing List for matplotlib (Page 10)

The RectangleSelector has parameters for the min span in the x and y directions of the rectangle.  The units of these are the axes units.  It would be nice if there was an additional similar min size requirement, but in units of pixels.  This way it would be independent of the axes scale.

Thanks,
-Ben

On Thu, Jul 10, 2008 at 6:42 AM, Angela Rivera Campos <riv...@in...> wrote:
> Hi,
>
> I'm quite a newbie on matplotlib.
>
> I'm trying to get some data from a file. I've got a function that reads
> the data from the file and stores it in a tuple as a set of floats. When
> I use this without importing pylab it just go well but when I do it
> after importing this module there's a rounding and I don't get the
> proper data:

My guess is there is something triggered by a pylab
numpy/numerix/Numeric import, but w/o kjnowing more about your
matplotlib and other software versions is it difficult to guess.
Could you put these lines into a test script and run them with

> python myscript.py --verbose-debug

and paste the output.

Florian Koelling recently reported a problem that sounded very similar
under the heading "mad interference between matplotlib and openbabel".
 Apparently some pylab import is doing something funky with some third
party libs.

Could you test just the numpy imports to see if that makes a
difference.  Ie, instead of importing pylab before your module code,
do the following:

import numpy
import numpy.fft
importnumpy.random
import numpy.linalg

and let us know if you see similar problems.

JDH


JDH

Tim Michelsen wrote:
> Hello Jeff, 
>
>   
>>>> - Points stored in the above descripbed format (lat, lon, value)?
>>>>         
> This one I solved using a m.scatter() function
>
>   
>>>> 	- Interpolate a grid of data points by using different interpolation
>>>> methods like inverse distance wheighting, natural neighbor 
>>>>         
> interpolation, etc. to get a contour map?
>   
>>> For interpolation of irregular, randomly distributed data points see
>>> http://www.scipy.org/Cookbook/Matplotlib/
>>>       
> Gridding_irregularly_spaced_data.
>   
>>> However, if there is some structure to the data grid then it's probably
>>> better not to use these approaches.
>>>       
> The problem is that although regular spaced the grid is still to large to
> countour to a nice map. I will play a bit more with contour and other
> interpolation functions.
>
> I tried griddata:
>
>   
>> 2) using the griddata package
>> Here I was nearly without orientation how to call griddata correctly.
>>     
> I tried again.
>
> Here is what I got:
>     x = data[:,1]
>     y = data[:,0]
>     z = data[:,2]
>     X, Y = mlab.meshgrid(x, y)
>     X, Z = mlab.meshgrid(x, y)
>     # zi = griddata(x,y,z,xi,yi,**kwargs)
>     Z = grid.griddata(x,y,z, X, Y)
> 	plt.contour(X,Y, Z)
> 	
> => ValueError: output grid defined by xi,yi must be monotone increasing
>
> The coordinates are stored in a way that first longitude (x) increases and
> then the latitude (y) increases.
> 10  6.0 4
> 10 6.25 3
> 10 6.50 2
> 10 6.75 1
> 10  6.0 6
> 11 6.25 7
> 11 6.50 6
> 11 6.75 9
> 12 6.0 4
>
> What how do I need to arrange my data to get it monotone increasing for
> griddata?
>
> Thanks for your help. One settled I will send you another example for the
> examples package.
>  
> Kind regards,
> Timmie
>
>   

Timmie:  You shouldn't use griddata.  You have a regular lat/lon grid, 
so it's just a matter of loading the data into the proper 2-d array.  
Please send a self-contained script (and post the data somewhere) and 
then we can help you.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

Le lundi 14 juillet 2008 à 09:08 -0400, Michael Droettboom a écrit :
> Do any other developers have better suggestions?  We may have to do some 
> magic in at drawing time (or convince the autoscaler to ignore the stem 
> lines) -- but I'd like to find a way that minimizes additional complexity.
> 
Is it possible do proceed as using axvline, i.e. specifying the axes
coordinates? In this case, it would require a mix of data coordinate
(the value to display) and of axes coordinate (the bottom of the curve).

When would values to render be converted ?
-- 
Fabrice Silva <si...@lm...>
LMA UPR CNRS 7051 - équipe S2M

Hello Jeff, 

> >> - Points stored in the above descripbed format (lat, lon, value)?
This one I solved using a m.scatter() function

> >> 	- Interpolate a grid of data points by using different interpolation
>>> methods like inverse distance wheighting, natural neighbor 
interpolation, etc. to get a contour map?
> > For interpolation of irregular, randomly distributed data points see
> > http://www.scipy.org/Cookbook/Matplotlib/
Gridding_irregularly_spaced_data.
> >
> > However, if there is some structure to the data grid then it's probably
> > better not to use these approaches.
The problem is that although regular spaced the grid is still to large to
countour to a nice map. I will play a bit more with contour and other
interpolation functions.

I tried griddata:

> 2) using the griddata package
> Here I was nearly without orientation how to call griddata correctly.
I tried again.

Here is what I got:
    x = data[:,1]
    y = data[:,0]
    z = data[:,2]
    X, Y = mlab.meshgrid(x, y)
    X, Z = mlab.meshgrid(x, y)
    # zi = griddata(x,y,z,xi,yi,**kwargs)
    Z = grid.griddata(x,y,z, X, Y)
	plt.contour(X,Y, Z)
	
=> ValueError: output grid defined by xi,yi must be monotone increasing

The coordinates are stored in a way that first longitude (x) increases and
then the latitude (y) increases.
10  6.0 4
10 6.25 3
10 6.50 2
10 6.75 1
10  6.0 6
11 6.25 7
11 6.50 6
11 6.75 9
12 6.0 4

What how do I need to arrange my data to get it monotone increasing for
griddata?

Thanks for your help. One settled I will send you another example for the
examples package.
 
Kind regards,
Timmie

This is a tricky one.  It appears this bug also exists in 0.91.x, 
perhaps earlier as well, so it isn't a regression.

I don't like the idea of setting the minimum to "1", especially for when 
the scale isn't log.  Setting it to a really small positive value (like 
1e-9) is better, but the autoscaling of the log plot then goes down to 
1e-9 as well.

Do any other developers have better suggestions?  We may have to do some 
magic in at drawing time (or convince the autoscaler to ignore the stem 
lines) -- but I'd like to find a way that minimizes additional complexity.

Cheers,
Mike

Dir...@in... wrote:
> Hello,
>
> I tried to do a stem plot on an Axes with logarithmic scale, experiencing that the stemlines were not drawn...
>
>
> ====axes.py (svn trunk, 2008-07-08):
> def stem(self, x, y, linefmt='b-', markerfmt='bo', basefmt='r-'):
> [...]
>     stemlines = []
>     for thisx, thisy in zip(x, y):
>         l, = self.plot([thisx,thisx], [0, thisy], linefmt)
>         stemlines.append(l)
>
>
> After Axes.set_yscale('log'), Axes.stem() no longer draws the stemlines because it tries to draw from y=0, thereby apparently triggering some guard which prevents plotting log(0), hence suppressing the complete stemline.
>
> Dirty hacking, I replace [0, thisy] with [1, thisy] in case yscale=='log' and it works for my plots, but for sure there is more to do to make it robust...
>
> Please give me a heads-up if I just oversaw the Right Way to do a stem plot with logarithmic yscale.
>
> Cheers,
> Dirk
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm surprised.  That works for me.  Can you (again) set verbose.level to 
"debug-annoying" and send the output?

Cheers,
Mike

David M. Kaplan wrote:
> Hi,
>
> Thanks for the suggestions.  I have stopped using the usetex option.  To
> make math and normal text match, I tried the following:
>
> rcParams['font.family'] = 'serif'
> rcParams['mathtext.fontset'] = 'stix'
>
> This didn't make them match - normal text looked to me like it was still
> sans-serif, while mathtext was with serif.  Is there something else I
> should be doing to make this happen?
>
> Thanks again for your help.
>
> Cheers,
> David
>
>
> On Thu, 2008-07-10 at 11:52 -0400, Darren Dale wrote:
>   
>> Hi David,
>>
>> On Thursday 10 July 2008 11:15:37 am David M. Kaplan wrote:
>>     
>>> 2) I have noticed that the font used for the xticklabels and the font
>>> used for the xlabel and contour labels appears to be different (example
>>> attached).  One appears to be serif and the other sans-serif.  This
>>> seems to be due to using tex for text rendering.  I am not sure if this
>>> also occurred before the update, but I didn't notice it previously.
>>>       
>> It has always been this way. We tried a workaround once a couple years back 
>> and it turned into a real mess.
>>
>>     
>>> Looking at the properties of the different text objects, it isn't
>>> apparent that there should be a difference - both have font properties
>>> that indicate sans-serif, but the text of tick labels appears to be
>>> surrounded by $'s forcing it through the text parser, while that of the
>>> contour labels is not.  Is this difference normal or expected?  Is there
>>> a way around this?  In particular, I would like to use sans-serif for
>>> everything - is this possible while still using tex?
>>>       
>> I think there is a package, sansmath or something like that, that will allow 
>> latex to use sans-serif fonts in math mode. You could try adding it to the 
>> text.latex.preamble rc setting, but that option is not officially supported.
>>
>> If you don't like the limitations of latex, you might want to turning off 
>> usetex and just use matplotlibs mathtext, which recently got a significant 
>> rewrite and is now quite capable thanks to Mike Droettboom. Here's some 
>> documentation too:
>> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html
>>
>> Darren
>>     

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jeff Whitaker wrote:
> Tim Michelsen wrote:
>   
>> Dear Matplotlib-Users,
>> I am tryring to create a contour plot over a basemap.
>>
>> My main problem is creating the array for the Z values as a basis for the
>> plt.contour command from a CSV file where latitude, longitude and value are
>> stored column-wise:
>>
>> lat;	lon;	value
>> 50;	10;	6
>> ...
>>
>> The data represents a regular spaced grid with a datapoint each 0.25 degrees.
>>
>> I tried various possibilities but didn't have success:
>>
>> 1) following simpletest.py from the basemap examples:
>> X, Y = meshgrid(data[:,1], data[:,0])
>>
>> Z = data[:,2]
>>   
>>     
> Timmie:  Try:
>
> X, Y = meshgrid(data[:,1], data[:,0])
> Z = data[:,2]
> nlons = X.shape[1]; nlats = X.shape[0]
> Z = Z.reshape(nlats,nlons)
>   

Timmie:  Sorry, but upon further reflection I don't think this will 
work.  You'll need to know the number of
lats and the number of lons on the grid beforehand.  Then you should be 
able to do

X = X.reshape(nlats,nlons)
Y = Y.reshape(nlats,nlons)
Z = Z.reshape(nlats,nlons)

after reading the data in.

(skip the meshgrid call, that's only useful when X is a vector with length nlons and Y is a vector with length nlats).

If you still have problems, send us a full example.

-Jeff



>   
>> m.contourf(x,y, Z)
>>
>> => Error: Z must be a 2D array
>> -> How do I get Z to be a 2D array?
>>
>> 2) using the griddata package
>> Here I was nearly without orientation how to call griddata correctly.
>>   
>>     
> You don't need to use griddata since you have regularly gridded data.
>   
>> 3) Using the python bindings of ogr
>> Any examples on this one?
>>   
>>     
> Again, no need.  A simple reshape will get you the 2d lat/lon array you 
> need.
>
>   
>> >From my above demonstrated methods the following questions arrise:
>> What is the preferred way to plot
>> 	- Points stored in the above descripbed format (lat, lon, value)?
>> 	- Interpolate a grid of data points by using different interpolation methods
>> like inverse distance wheighting, natural neighbor  interpolation, etc. to get a
>> contour map?
>>   
>>     
>
> For interpolation of irregular, randomly distributed data points see
> http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data.
>
> However, if there is some structure to the data grid then it's probably 
> better not to use these approaches.
>
> -Jeff
>
>
>
>   


-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

Tim Michelsen wrote:
> Dear Matplotlib-Users,
> I am tryring to create a contour plot over a basemap.
>
> My main problem is creating the array for the Z values as a basis for the
> plt.contour command from a CSV file where latitude, longitude and value are
> stored column-wise:
>
> lat;	lon;	value
> 50;	10;	6
> ...
>
> The data represents a regular spaced grid with a datapoint each 0.25 degrees.
>
> I tried various possibilities but didn't have success:
>
> 1) following simpletest.py from the basemap examples:
> X, Y = meshgrid(data[:,1], data[:,0])
>
> Z = data[:,2]
>   
Timmie:  Try:

X, Y = meshgrid(data[:,1], data[:,0])
Z = data[:,2]
nlons = X.shape[1]; nlats = X.shape[0]
Z = Z.reshape(nlats,nlons)

> m.contourf(x,y, Z)
>
> => Error: Z must be a 2D array
> -> How do I get Z to be a 2D array?
>
> 2) using the griddata package
> Here I was nearly without orientation how to call griddata correctly.
>   
You don't need to use griddata since you have regularly gridded data.
>
> 3) Using the python bindings of ogr
> Any examples on this one?
>   
Again, no need.  A simple reshape will get you the 2d lat/lon array you 
need.

> >From my above demonstrated methods the following questions arrise:
> What is the preferred way to plot
> 	- Points stored in the above descripbed format (lat, lon, value)?
> 	- Interpolate a grid of data points by using different interpolation methods
> like inverse distance wheighting, natural neighbor  interpolation, etc. to get a
> contour map?
>   

For interpolation of irregular, randomly distributed data points see
http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data.

However, if there is some structure to the data grid then it's probably 
better not to use these approaches.

-Jeff



-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

Dear Matplotlib-Users,
I am tryring to create a contour plot over a basemap.

My main problem is creating the array for the Z values as a basis for the
plt.contour command from a CSV file where latitude, longitude and value are
stored column-wise:

lat;	lon;	value
50;	10;	6
...

The data represents a regular spaced grid with a datapoint each 0.25 degrees.

I tried various possibilities but didn't have success:

1) following simpletest.py from the basemap examples:
X, Y = meshgrid(data[:,1], data[:,0])

Z = data[:,2]

m.contourf(x,y, Z)

=> Error: Z must be a 2D array
-> How do I get Z to be a 2D array?

2) using the griddata package
Here I was nearly without orientation how to call griddata correctly.


3) Using the python bindings of ogr
Any examples on this one?

>From my above demonstrated methods the following questions arrise:
What is the preferred way to plot
	- Points stored in the above descripbed format (lat, lon, value)?
	- Interpolate a grid of data points by using different interpolation methods
like inverse distance wheighting, natural neighbor  interpolation, etc. to get a
contour map?

Thanks in advance for your help & kind regards,
Timmie

> Try
> 
>   import pylab
> 
> instead of
> 
>   from pylab import *
> 
> Manuel
> 


I've already tried using
	
	import pylab

and also just importing the functions that I'm using, but the result is 
always the same.

AR

I've been trying to build and install matplotlib now for a few days, and 
have met with no success. I'm running OSX 10.5.4 on a MacBook Pro, 
Python 2.5.2 from MacPython, gcc 4.0.1, gfortran 4.3.0, and the latest 
version of Apple's XCode (3.1, which, if I understand correctly, has the 
necessary libpng and freetype libraries). I've got numpy 1.2.0 and scipy 
0.6.0 installed so far. I'd read that I should set the following 
environment variables prior to building:

export MACOSX_DEPLOYMENT_TARGET=10.5
export CFLAGS="-arch i386 -arch ppc -isysroot 
/Developer/SDKs/MacOSX10.5.sdk"
export LDFLAGS="-arch i386 -arch ppc 
-isyslibroot,/Developer/SDKs/MacOSX10.5.sdk"

Building starts off OK:

============================================================================
BUILDING MATPLOTLIB
             matplotlib: 0.98.1
                 python: 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)  [GCC
                         4.0.1 (Apple Computer, Inc. build 5363)]
               platform: darwin

REQUIRED DEPENDENCIES
                  numpy: 1.2.0.dev5312
              freetype2: 9.16.3

OPTIONAL BACKEND DEPENDENCIES
                 libpng: 1.2.8
                Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
               wxPython: 2.8.3.0
                         * WxAgg extension not required for wxPython >= 2.8
                   Gtk+: no
                         * Building for Gtk+ requires pygtk; you must be 
able
                         * to "import gtk" in your build/install environment
                     Qt: no
                    Qt4: no
                  Cairo: no

OPTIONAL DATE/TIMEZONE DEPENDENCIES
               datetime: present, version unknown
               dateutil: matplotlib will provide
                   pytz: matplotlib will provide

OPTIONAL USETEX DEPENDENCIES
                 dvipng: 1.5
            ghostscript: 8.61
                  latex: 3.141592

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
              configobj: matplotlib will provide
       enthought.traits: 2.6b1-mpl

[Edit setup.cfg to suppress the above messages]
============================================================================

... but eventually chokes:

g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g 
-bundle -undefined dynamic_lookup -arch i386 -arch ppc 
-isyslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 -arch ppc 
-isysroot /Developer/SDKs/MacOSX10.5.sdk 
build/temp.macosx-10.5-fat-2.5/src/ft2font.o 
build/temp.macosx-10.5-fat-2.5/src/mplutils.o 
build/temp.macosx-10.5-fat-2.5/CXX/cxx_extensions.o 
build/temp.macosx-10.5-fat-2.5/CXX/cxxsupport.o 
build/temp.macosx-10.5-fat-2.5/CXX/IndirectPythonInterface.o 
build/temp.macosx-10.5-fat-2.5/CXX/cxxextensions.o -L/usr/X11/lib 
-L/sw/lib/freetype219/lib -L/usr/local/lib -L/usr/lib -L/sw/lib 
-L/usr/X11R6/lib -lfreetype -lz -lz -lstdc++ -lm -o 
build/lib.macosx-10.5-fat-2.5/matplotlib/ft2font.so 
-Wl,-framework,CoreServices,-framework,ApplicationServices
ld warning: in 
/Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.10.5.dylib, 
missing required architecture i386 in file
ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.1.dylib, 
missing required architecture i386 in file for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file: 
/var/folders/mX/mXK0L5vQF7elQu1RMPhkyU+++TI/-Tmp-//cc1JpFBv.out (No such 
file or directory)
error: command 'g++' failed with exit status 1

It looks to me as if ld is trying to link to the wrong SDK (10.4 instead 
of 10.5) which might not be built for Intel Macs... is that right? Is 
that actually what's causing the build to fail? I'm totally stuck, and 
would appreciate any advice.

-P



-- 
Peter A. Selkin
Assistant Professor, Environmental Geophysics
IAS/Environmental Science
University of Washington, Tacoma
1900 Commerce St., Box 358436
Tacoma, WA 98402

paselkin@u.washington.edu

hi,

> 1. Would it be possible to do only shallow copy of the arrays that are
> being plotted so that on redrawing the figure, chanes in the datasets
> would be picked up automatically? If not, is Line2D.set_data(...) the
> right approach?
isn't this the way how the plotting is done? in my experience (iirc), 
the following thing works (x, y1, y2 are numpy arrays):

pylab.ion()

a, = pylab.plot(x,y1)
b, = pylab.plot(x,y2)
...
y1 += 10
y2 += 20

a.set_ydata(y1)
b.set_ydata(y2)
pylab.draw()

y1 += 10
y2 += 20
a.set_ydata(y1)
pylab.draw()

in my experience BOTH plots get updated in this procedure, so i have to 
do first a deep copy in my case to get rid of these 'unwanted effects'...

best,

-- 
Lubos _@_"
http://www.lubos.vrbka.net

On Fri, Jul 11, 2008 at 11:55 AM, James K. Gruetzner <jk...@sa...> wrote:

> And that's as far as I can go in this:  I'm not graphics whiz, and, in fact,
> having reached somewhat beyond my skill level,  can't even figure out how to
> trace the mainloop call back further.

To make sure I capture all the events that can close the window, I
usually connect to the delete-event and the destroy-event.  Eg::

  win.connect("delete_event", gtk.mainquit)
  win.connect("destroy_event", gtk.mainquit)

where win is your gtk window.

JDH

On Sat, Jul 12, 2008 at 2:35 PM, John Hunter <jd...@gm...> wrote:
> On Sat, Jul 12, 2008 at 3:09 PM, Barry Wark <bar...@gm...> wrote:
>> Work is currently going in the wrong direction for me to be able to
>> implement toolbars etc. in a timely manner. Would you be willing to
>> add the rc parameter you discussed so that backend could be defined in
>> a separate package? This would allow me to continue working on (and
>> deploying internally) the Cocoa native backend. As soon as it meets
>> the requirements, I will be happy to resubmit it for inclusion with
>> the matplotlib distribution (including supporting it going forward).
>
> I just committed some changes to svn to support the syntax
> module://some_backend to load the backend from a module in the
> pythonpath.  Give it a test drive and see if it works in your use
> cases.  The matplotlibrc file, the use directive and the -d argument
> to pylab will all respect this syntax, eg
>
>  matplotlib.use('module://backend_cocoa')
>
> or
>
>  > python simple_plot.py -dmodule://my_backend
>
> but backend_cocoa doesn't currently work with pylab...
>
> Outside of of pylab, it doesn't matter much because you could already
> import directly from your own modules if you are building apps, but at
> least the backend validation machinery won't complain if it sees
> something starting with 'module://'
>
> Let me know if you had something different in mind....

This looks like exactly what I had in mind. Thanks! A quick test seems
to work and I will ping you if I find issues upon digging deeper.
Thanks!

Barry

On Sat, Jul 12, 2008 at 3:09 PM, Barry Wark <bar...@gm...> wrote:
> Work is currently going in the wrong direction for me to be able to
> implement toolbars etc. in a timely manner. Would you be willing to
> add the rc parameter you discussed so that backend could be defined in
> a separate package? This would allow me to continue working on (and
> deploying internally) the Cocoa native backend. As soon as it meets
> the requirements, I will be happy to resubmit it for inclusion with
> the matplotlib distribution (including supporting it going forward).

I just committed some changes to svn to support the syntax
module://some_backend to load the backend from a module in the
pythonpath.  Give it a test drive and see if it works in your use
cases.  The matplotlibrc file, the use directive and the -d argument
to pylab will all respect this syntax, eg

  matplotlib.use('module://backend_cocoa')

or

  > python simple_plot.py -dmodule://my_backend

but backend_cocoa doesn't currently work with pylab...

Outside of of pylab, it doesn't matter much because you could already
import directly from your own modules if you are building apps, but at
least the backend validation machinery won't complain if it sees
something starting with 'module://'

Let me know if you had something different in mind....

JDH

Tony S Yu wrote:
> On Jul 12, 2008, at 1:50 PM, Alan wrote:
> 
>> Hi List,
>>
>> I use Fink for Mac OSX, tiger 10.4.11.
>>
>> So with MPL 0.90.1, this script works fine:
>>
>> from matplotlib.pylab import *
>> import matplotlib, numpy
>> print matplotlib.__version, numpy.__version__
>> att1 = {'color': 'black', 'markerfacecolor': 'red', 'markersize':
>> 80.0, 'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 's',
>> 'markeredgecolor': 'blue'}
>> att2 = {'color': 'black', 'markerfacecolor': None, 'markersize': 8.0,
>> 'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 'o',
>> 'markeredgecolor': 'blue'}
>> plot([0],[0], **att1)
>> plot([0],[0], **att2)
>> show()
>>
>> I got just a blue circle line (not filled) over a red square. However,
>> trying the same script with updated MPL 0.91.3, I got:
>>
>> [snip]
>>  File "/sw/lib/python2.5/site-packages/matplotlib/colors.py", line
>> 279, in to_rgb
>>    raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg),  
>> exc))
>> ValueError: to_rgb: Invalid rgb arg "None"
>> cannot convert argument to rgb sequence

The error message is somewhat misleading in this case because of the 
quotes; it is failing on the Python object None, not the string "None".

>>
>> Bottom line, version 0.91.3 simply doesn't like 'markerfacecolor':
>> None anymore.
> 
> Could you try setting 'markerfacecolor' to 'none' (Note that this is  
> the string, not the keyword). I'm on version 0.98.2, but I think this  
> worked when I was using 0.91.3. I'm not sure why this change was made,  
> though.

We have been trying to move to the following standard for kwargs:

None (the Python object) means "use the default", usually an rcParams 
setting.  (In the case of markerfacecolor, it is not an rcParams value, 
it is the 'color' value.)

'none' or 'None' means "no color".

There is indeed a bug in the present code: 'markerfacecolor': None is 
raising an error because it is supposed to be converted to the default, 
which is 'auto', but when it is input as a plot kwarg, it isn't.  I will 
have that fixed shortly in the two svn branches.

Eric

> 
> Best,
> -Tony
> 
>>
>> So, is it a bug, or there's another way of getting a simple circle  
>> not filled?
>>
>> Many thanks in advance,
>> Alan

Work is currently going in the wrong direction for me to be able to
implement toolbars etc. in a timely manner. Would you be willing to
add the rc parameter you discussed so that backend could be defined in
a separate package? This would allow me to continue working on (and
deploying internally) the Cocoa native backend. As soon as it meets
the requirements, I will be happy to resubmit it for inclusion with
the matplotlib distribution (including supporting it going forward).

Barry

On Thu, Jul 3, 2008 at 12:14 PM, Barry Wark <bar...@gm...> wrote:
> On Thu, Jul 3, 2008 at 8:41 AM, John Hunter <jd...@gm...> wrote:
>> On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark <bar...@gm...> wrote:
>>> I've written the start of a Cocoa-native backend for matplotlib and
>>> would like to submit feedback on the code and on the possibility of
>>> including it in the standard matplotlib distribution. The backend
>>
>> Hey Barry,
>>
>> This is great and it is something we are interested in.  I haven't had
>> a chance to test it and will be away next week but I can give you some
>> initial thoughts.  In general, we want to pare down the number of
>> backends but OS X is an important platform and there are certainly
>> some advantages to doing native rendering.  For us to accept a new
>> backend, we need to meet the following criteria:
>>
>>  - someone volunteers to support it.  This is a multi-year
>> commitment.  Presumably this would be you.
>
> Yes.
>
>>
>>  - feature complete - images, mathtext, rotated text, etc...  It
>> sounds like the only part you are unsure about is mathtext so perhaps
>> Michael can advise.  I don't think it will be too hard since Michael
>> has designed this to work with unicode fonts if requested.
>
> Using unicode fonts should make it easy.
>
>>
>>  - gui backends: toolbar support
>
> Currently not implemented, but not a problem.
>
>>
>> If you think these are doable, that would be great.  If not, I think
>> we can rework the backend infrastructure a bit to support external
>> backend, eg an rc backend setting which points to a file that contains
>> the backend implementation.  This latter is worth doing in any case,
>> so if you want to have a look at it....
>
> This would be _very_ useful, whether or not you decide to include a
> Cocoa native backend in the distribution. Perhaps also making it
> possible to delegate to an other package instead of just a file so
> that backends could be installed as separate eggs would be useuful
> (e.g. delegate the backend to my.package.backend).
>
>>
>>> implementation is not complete (image rendering and mathtext rendering
>>> are currently no implemented, nor are the print_* methods of the
>>> FigureCanvas). Image rendering is trivial once I figure out how to get
>>> the pixel data out of a matplotlib image (I just haven't investigated
>>> the API yet). The print_* methods are also trivial (see point 1
>>> below). I'm not sure how to handle mathtext yet. This backend has two
>>> major feature differences from CocoaAgg:
>>
>>> 2. The reason I wrote the backend was so that matplotlib could be used
>>> seemlesslly from within a Cocoa application. Thus this backend *will
>>> not work* without an existing NSRunLoop. It won't work from the
>>> terminal or an IPython session. It will work from the in-progress
>>> Cocoa frontend for IPython or from any other Cocoa application. Again
>>> there are tradeoffs. On the positive side, figure windows are treated
>>> like any other application window, selectable from the Window menu
>>> etc. and matplotlib becomes a seemless part of the application.
>>> Existing backends designed to create their own runloop (e.g. CocoaAgg
>>> or TkAgg) cause menubar and run loop problems when used from within an
>>> existing application. It would be possible to merge the CocoaAgg and
>>> Cocoa backends in this regard to use the existing run loop if present.
>>
>> I know nothing about cocoa apps, but from the way you describe this  I
>> think there may be some confusion in how the backends should work.  I
>> will speak in terms of gtk since this is the toolkit I know best.  The
>> FigureCanvas should be a widget which is embeddable in an app (in a
>> container or window, etc) -- the gtk figure canvas is such a widget
>> and can be used in a gtk app and mpl knows nothing about the
>> application or mainloop -- that part is up to the application
>> developer.  The FigureManager is basically a pylab helper class and is
>> not meant to be used by the application developer, though I think some
>> backends may have been designed differently (eg wx).  The
>> FigureManager creates a canvas, a toolbar and a window, and puts all
>> the pieces together.  "show" is a pylab construct that raises the
>> active windows and starts the mainloop.
>
> No, in fact you've done a very good job of communicating the
> architecture and it appears that it was my mistake in explaining my
> work that's led to confusion. backend_cocoa.FigureCanvasView (a
> FigureCanvas subclass) is an NSView subclass that can be embedded in a
> Cocoa application to render matplotlib figures.
>
> We have a special use case in mind for the
> backend_cocoa.FigureManagerCocoa (the FigureManager subclass),
> however. I'm not sure if you've been following discussions on the
> ipython-dev regarding GUI frontends for IPython, so let me briefly
> recap. The new Twisted-based architecture of IPython now allows easy
> development of GUI frontends for the IPython engine because the engine
> is decoupled from readline. Thus a Cocoa-based frontend for IPython
> might behave like a terminal but be implemented as a native Cocoa
> widget that can be embedded in other applications. We want the user of
> this GUI IPython frontend to be able to use matplotlib as if in a
> pylab session at the terminal. Because there's already an NSRunLoop
> running, however, the existing backends that attempt to start their on
> run loop cause problems. I imagine GUI frontends (on OS X) doing a
> matplotlib.use('Cocoa') at startup but the user keeping their existing
> backend for terminal usage. I haven't yet explored the
> FigureManagerCocoa creating its own runloop if none exists. If you
> want to try the new IPython frontend (still very much a work in
> progress), have a look in the IPython/frontend/cocoa/examples
> directory of IPython trunk (launchpad.net/ipython).
>
> Thus there are really two different aspects to consider for backend_cocoa
> 1. Native rendering. this may or may not be valuable. If valuable, we
> could merge this renderer into the existing CocoaAgg backend,
> replacing the FiureCanvas that blits from the Agg renderer.
> 2. A FigureManager for use *within* a running cocoa application. I
> will investigate using the FigureManagerCocoa from terminal as well,
> but that's not the use case I wrote it for.
>
> Although I personally think (2) (in conjunciton with a native forntend
> for IPython) is the way of the future on OS X, it may still be too
> small a use case for you to feel its inclusion in matplotlib is
> valuable. In that case, being able to delegate the backend to an other
> package  as discussed above would meet our needs.
>
>>
>> So your backend *should* be designed so that it can be run from the
>> shell, basically you need to create an application within the backend
>> and start the mainloop with show -- this app will only be created in
>> pylab mode on calls to new_figure_manager and show.  I don't know if
>> any of this makes sense for cocoa apps, but it is a nice feature for
>> backends because then those of us who do not know how to build a cocoa
>> app (and maybe don't want to learn) can still test the backend on
>> pylab scripts and regular os x users can use your backend w/ pylab
>> scripts.
>
> backend_cocoaagg already does this. if there's a compelling reason to
> move to the native renderer, we could merge that into
> backend_cocoaagg. backend_cocoa provides a separate functionality --
> simulating a pylab session from within a native GUI frontend for
> IPython.
>
>>
>> JDH
>>
>

On Jul 12, 2008, at 1:50 PM, Alan wrote:

> Hi List,
>
> I use Fink for Mac OSX, tiger 10.4.11.
>
> So with MPL 0.90.1, this script works fine:
>
> from matplotlib.pylab import *
> import matplotlib, numpy
> print matplotlib.__version, numpy.__version__
> att1 = {'color': 'black', 'markerfacecolor': 'red', 'markersize':
> 80.0, 'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 's',
> 'markeredgecolor': 'blue'}
> att2 = {'color': 'black', 'markerfacecolor': None, 'markersize': 8.0,
> 'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 'o',
> 'markeredgecolor': 'blue'}
> plot([0],[0], **att1)
> plot([0],[0], **att2)
> show()
>
> I got just a blue circle line (not filled) over a red square. However,
> trying the same script with updated MPL 0.91.3, I got:
>
> [snip]
>  File "/sw/lib/python2.5/site-packages/matplotlib/colors.py", line
> 279, in to_rgb
>    raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg),  
> exc))
> ValueError: to_rgb: Invalid rgb arg "None"
> cannot convert argument to rgb sequence
>
> Bottom line, version 0.91.3 simply doesn't like 'markerfacecolor':
> None anymore.

Could you try setting 'markerfacecolor' to 'none' (Note that this is  
the string, not the keyword). I'm on version 0.98.2, but I think this  
worked when I was using 0.91.3. I'm not sure why this change was made,  
though.

Best,
-Tony

>
>
> So, is it a bug, or there's another way of getting a simple circle  
> not filled?
>
> Many thanks in advance,
> Alan
> -- 
> Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
> Department of Biochemistry, University of Cambridge.
> 80 Tennis Court Road, Cambridge CB2 1GA, UK.
>>> http://www.bio.cam.ac.uk/~awd28<<
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi List,

I use Fink for Mac OSX, tiger 10.4.11.

So with MPL 0.90.1, this script works fine:

from matplotlib.pylab import *
import matplotlib, numpy
print matplotlib.__version, numpy.__version__
att1 = {'color': 'black', 'markerfacecolor': 'red', 'markersize':
80.0, 'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 's',
'markeredgecolor': 'blue'}
att2 = {'color': 'black', 'markerfacecolor': None, 'markersize': 8.0,
'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 'o',
'markeredgecolor': 'blue'}
plot([0],[0], **att1)
plot([0],[0], **att2)
show()

I got just a blue circle line (not filled) over a red square. However,
trying the same script with updated MPL 0.91.3, I got:

[snip]
  File "/sw/lib/python2.5/site-packages/matplotlib/colors.py", line
279, in to_rgb
    raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
ValueError: to_rgb: Invalid rgb arg "None"
cannot convert argument to rgb sequence

Bottom line, version 0.91.3 simply doesn't like 'markerfacecolor':
None anymore.

So, is it a bug, or there's another way of getting a simple circle not filled?

Many thanks in advance,
Alan
-- 
Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
Department of Biochemistry, University of Cambridge.
80 Tennis Court Road, Cambridge CB2 1GA, UK.
>>http://www.bio.cam.ac.uk/~awd28<<

James K. Gruetzner wrote:
> I don't really need any live interaction or a live data display; I just want 
> the thang to stop running (i.e., the process to terminate) when the figure 
> window is closed.  
> 
> Unfortunately, the 
>   dynamic_image_gtkagg.py
> example has the same problem.  It's final line is "show()".  When run as a 
> background process, everything displays well --- but when the window is 
> closed (click on X), the process fails to terminate.   So . . . the root 
> cause is that show() does not return when the shown image is closed.  
> 
>> If you *need* it to wait for user interaction before continuing, there might
>> be a little bit more work, but I don't think it'd be much.  You could
>> probably instead look at some of the Matplotlib UI widgets, like in the
>> buttons.py example.
> 
> I really don't need user interaction per se,  I may have to go that route an 
> establish some sort of "close window and exit" event.  Hmmm:  another 
> learning opportunity . . . .  :-)  
> 
> The show() function is defined in
>     .../matplotlib/backends/backend_gtk.py
> and looks to be calling gtk.main(), which, according to 
>    .../gtk-2.0/gtk/__init__.py
> appears to be deprecated in favor of mainloop().
> 
> And that's as far as I can go in this:  I'm not graphics whiz, and, in fact, 
> having reached somewhat beyond my skill level,  can't even figure out how to 
> trace the mainloop call back further.  
> 
> I would think that the gtk mainloop would terminate when the window closes 
> (which termination should propagate back up the stack), but apparently that 
> doesn't happen.

I'm not sure I'm following you at the moment.  Are you calling show() 
once and closing the figure doesn't cause it to return?   or are you 
trying to call show() multiple times from a single script and subsequent 
calls to show() fail to return?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Jul 8, 2008, at 4:47 PM, Michael Muratet wrote:

> Greetings
>
> I am trying to install matplotlib 0.98.1 on python 2.5.1 on Mac OS X
> 10.5.3. The install breaks at the required dependancy numpy 1.1
> because it thinks it has v 1.0.1. I have, in fact, installed numpy 1.1
> and I can't figure out why the matplotlib installer is not seeing it.
> I am not entirely familiar with installing python tools on Macs. Can
> anyone point out a build parameter or a common newbie error or any
> other info so I can resolve the dependancy?

This is happening because Leopard comes with an older version of numpy  
already installed in:
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ 
python

I'm pretty sure that this searched in before the path where your numpy  
install is. This issue has come up before in many places, here's one:
http://mail.python.org/pipermail/pythonmac-sig/2008-January/019596.html

I'm not sure what the current "best practice" is thought to be. You  
should be able to change your PYTHONPATH environment variable to load  
the correct directory first.

Some suggest to install your own (newer) version of python from  
python.org for your own use and leave the system python for Apple's  
use. You can then easily install the numpy/scipy/matplotlib/ipython  
tools with the "Scipy superpack" installer:
http://macinscience.org/?page_id=6

An easier route might be to use the enthought distribution (if their  
licensing is OK with you):
http://enthought.com/products/epddownload.php

It installs its on Python framework in:
"/Library/Frameworks/Python.framework/Versions/2.5.2001"

And numpy,scipy,ipython,matplotlib all just work out of the box.

-steve

On Wed, Jul 9, 2008 at 1:55 PM, Michael Muratet
<mmu...@hu...> wrote:

> I am running on a Mac OS X 10.5 system and even though I set the
> CFLAGS and LDFLAGS I can't seem to point the build to the correct tree.
>
> Note: I am a newbie relative to python on a Mac.
>
> Can anyone point out an error I've made or offer troubleshooting
> suggestions?

My OS X build notes are at
http://ipython.scipy.org/moin/Py4Science/InstallationOSX and Charlie's
(who does the binary mpl builds) are at
http://ipython.scipy.org/moin/MatplotlibOSXBuildNotes.  From the
output you posted, it looks like it the freetype and png headers are
not found, which means either you haven't installed x-code package,
pkgconfig is not installed or the PKG_CONFIG_PATH is not set.  Also,
the error complains about the architecture ppc not being included in
the libpng build

The following may help prevent the compiler from trying to build/link
the ppc libraries

  CFLAGS="-Os -arch i386" LDFLAGS="-Os -arch i386" python setup.py build

Charlie includes notes on how to properly build universal png and freetype libs.

JDH

Thanks to Eric and Fernando
I will try to update ipython (for some reason I have troubles with that in
windows).
The ipython -pylab[...]
with who() command works but it seems to work only for arrays.
i.e. with x = arange(20) it worked but not with x=1.
Hence updating ipython remains the only way.

Thanks
Eli



On Fri, Jul 11, 2008 at 3:57 PM, Eric Firing <ef...@ha...> wrote:

> Eli Brosh wrote:
>
>> Thanks Fernando,
>> I now tried %who.
>> The result was a huge output, apparently containing all the pylab
>> functions.
>> This is exactly the thing I was trying to avoid.
>> I wanted to use the who command to see only the variables I defined as
>> part of the pylab session.
>>
>> Is there a way to do just this ?
>>
>
> Maybe the pylab command does what you want; you have to include the
> trailing parentheses:
>
> efiring@manini:~$ ipython -pylab
> [...]
>
> In [2]:x = arange(20)
>
> In [3]:who()
> Name            Shape            Bytes            Type
> ===========================================================
>
> x               20               80               int32
>
> Upper bound on total bytes  =       80
>
>
> Eric
>

Darren Dale wrote:
> On Friday 11 July 2008 04:20:07 am Neil Pilgrim wrote:

>> Lastly, has anyone checked whether 0.98 still has the 'down key' bug for
>> key-press events? (is there a bugzilla/tracker?)
> 
> I'm not familiar with this issue.

I've not used 0.98, and I just noticed that debian etch actually has 
0.87.7, so I'm 'only' using the latter, nothing more recent...

The bug was mentioned in 2005 according to this archived message:
http://osdir.com/ml/python.matplotlib.general/2005-04/msg00118.html

Triggering 'down' key events do not work correctly - I guess only in the 
gtkagg backend. I have reproduced this here.

-- 
Neil