Re: [Matplotlib-users] 3D plots
On Mon, Mar 23, 2009 at 6:11 AM, Etienne Gaudrain et.gaudr...@free.fr wrote: Thanks a lot for the link, and for the suggestions! I will probably give a go to Mayavi2, but given how heavy it seems to be (compared to matplotlib) it probably requires some custom wrapping... which means again a lot time investment... thanks for the tips anyway! Etienne, I believe that Mayavi2 has a matlab-like interface (called mlab, I think) which offers a much higher-level (and more command-line friendly) API. I'm not a Mayavi expert by any streach, but you may be able to find many helpful folks on the enthought-dev list (https://mail.enthought.com/mailman/listinfo/enthought-dev) cheers, Barry Cheers, -Etienne Gary Ruben wrote: Hi Etienne, Sorry to hear about your disappointment. You can read about the attempt to resurrect the 3D plotting capabilities here: http://www.nabble.com/Updating-MPlot3D-to-a-more-recent-matplotlib.-td22302256.html Unfortunately, this doesn't help you right now. Depending on the type of 3D plotting you want to do, some suggestions for other packages that support 3D plotting from Python and work now are: Mayavi2's mlab interface http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab_3d_plotting_functions.html gnuplot.py http://gnuplot-py.sourceforge.net/ DISLIN http://www.mps.mpg.de/dislin R via RPy http://rpy.sourceforge.net/ and I'm pretty sure there are more too. Right now, if mayavi2 looks like it'll do what you want, I'd recommend it as your next stop. And in my opinion, I wouldn't say that your time spent learning matplotlib was wasted - 2D plotting is usually useful and matplotlib may soon again have limited 3D capability. Gary R. Etienne Gaudrain wrote: Hello list ! This is probably a recurrent topic, or even more probably HAVE been a recurrent topic... So sorry, sorry, sorry... I wanted to search the archives but Sourceforge is very slow today (...). Anyway, here is my question: Is it right that Matplotlib can no longer plot 3D graphes? snip Does it mean that all my efforts to understand and learn Matplotlib are just a big waste of time since I need another package now that I need 3D plot? So I ask you for advice: should I forget completely Matplotlib and move to MayaVI2? Or is there any plan to bring 3D back into Matplotlib, I mean to make a proper and complete alternative to Matlab? Or am I just upset because I am missing something. I only plot data every 4 or 6 months, and I really don't expect to see major functionalities to have disappeared when I come back to plotting data... is it a wrong expectation? Thanks !! -Etienne -- ~ Etienne Gaudrain Centre for the Neural Basis of Hearing Department of Physiology, Development and Neuroscience University of Cambridge Downing Street Cambridge CB2 3EG UK Phone: +44 (1223) 333 859 office Fax: +44 (1223) 333 840 department ~ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application
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 [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:41 AM, John Hunter [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark [EMAIL PROTECTED] 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
Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application
On Sat, Jul 12, 2008 at 2:35 PM, John Hunter [EMAIL PROTECTED] wrote:
On Sat, Jul 12, 2008 at 3:09 PM, Barry Wark [EMAIL PROTECTED] 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
-
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application
On Thu, Jul 3, 2008 at 8:41 AM, John Hunter [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark [EMAIL PROTECTED] 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-users] Cocoa backend for embedding in Cocoa application
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
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:
1. All drawing is done via native Quartz drawing calls. This has the
advantage of making all of the native rendering functionality
(including native font rendering and output formats (all those
supported by Cocoa-eps,pdf,tiff,etc.) available to matplotlib. It has
the disadvantage that the translation from matplotlib paths to Cocoa
NSBezierPaths is done in python and is much slower than the compiled
version of this operation in the Agg backend (this is a solvable
problem, of course).
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've attached the backend_cocoa.py.
cheers,
Barry
# encoding: utf-8
The Cocoa backend is a Quartz-native backend for Matplotlib for using
Matplotlib from *within* a Cocoa application (one that already has an
NSRunLoop).
from __future__ import division
__docformat__ = restructuredtext en
# Cocoa specific
from Foundation import *
from AppKit import *
# matplotlib
import matplotlib
from matplotlib._pylab_helpers import Gcf
from matplotlib.figure import Figure
from matplotlib.backend_bases import RendererBase, GraphicsContextBase,\
FigureCanvasBase, FigureManagerBase
from matplotlib.path import Path
from matplotlib.transforms import Bbox, Affine2D
import numpy as np
# Testing
import unittest
import nose
POINTS_PER_INCH = 72.0
# Memoize (from http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496879).
# Modified to skip first arg (self, since it'll be an NSObject)
import cPickle
def memoize(function, limit=None):
if isinstance(function, int):
def memoize_wrapper(f):
return memoize(f, function)
return memoize_wrapper
dict = {}
list = []
def memoize_wrapper(*args, **kwargs):
key = cPickle.dumps((args[1:], kwargs))
try:
list.append(list.pop(list.index(key)))
except ValueError:
dict[key] = function(*args, **kwargs)
list.append(key)
if limit is not None and len(list) limit:
del dict[list.pop(0)]
return dict[key]
memoize_wrapper._memoize_dict = dict
memoize_wrapper._memoize_list = list
memoize_wrapper._memoize_limit = limit
memoize_wrapper._memoize_origfunc = function
memoize_wrapper.func_name = function.func_name
return memoize_wrapper
class RendererCocoa(RendererBase):
The renderer handles drawing/rendering operations.
RendererCocoa renders into an NSView instance
fontWeights = {
100 : u'',
200 : u'',
300 : u'',
400 : u'',
500 : u'',
600 : u'Bold',
700 : u'Bold',
800 : u'Bold',
900 : u'Bold',
'ultralight' : u'',
'light' : u'',
'normal' : u'',
'medium' : u'',
'semibold' : u'Bold',
'bold' : u'Bold',
'heavy' : u'Bold',
'ultrabold' : u'Bold',
'black' : u'Bold',
}
fontAngles = {
'italic' : u'Italic',
'normal' : u'',
'oblique' : u'Oblique',
}
lineJoinStyle = {
'miter' : NSMiterLineJoinStyle,
'round' : NSRoundLineJoinStyle,
'bevel' : NSBevelLineJoinStyle
}
lineCapStyle = {
'butt' : NSButtLineCapStyle,
'round' : NSRoundLineCapStyle,
'projecting': NSSquareLineCapStyle,
}
Re: [Matplotlib-users] Best installation procedure for MacOSX
José, I would take a look at the Scipy Superpack (http://trichech.us/). Alternatively, you can download and install the MacPython 2.5 for OS X 10.4 (http://www.pythonmac.org/packages/py25-fat/index.html). This installs a separate Python framework (leaving the system python framework unchanged). The installer will modify your path to point to the new python2.5. You can then install setuptools/ipython/numpy/scipy/matplotlib from source or via EasyInstall. If you go this route, you'll probably also want the wxPython installer from http://www.wxpython.org/download.php#binaries. Feel free to contact me directly if you have any other questions. Barry On Feb 15, 2008 6:23 AM, José Gómez-Dans [EMAIL PROTECTED] wrote: Hi! Some colleagues are starting to use python, matplotlib et al. for data analysis and so on. However, they are using MacOSX computers, and neither of us are particularly proficient in the use of OSX. I would like to know if there's an easy way to install ipython, numpy, scipy and matplotlib on MacOSX 10.4 without much hassle. Is there some officially sanctioned :D best way? Cheers! Josea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Best installation procedure for MacOSX
On Feb 15, 2008 1:27 PM, Christopher Barker [EMAIL PROTECTED] wrote: Barry Wark wrote: I'm ramping up to start building at least scipy binaries (see recent post on scipy-users list). I'm just waiting for tester feedback for eggs built from SVN trunk. They're currently for OS X 10.5, but I will also build for MacPython once I'm sure everything's working. Great, thanks! numpy, ipython, and matplotlib all apear to be available via EasyInstall, so scipy seems to be the only missing piece. well, it's the hard one, as it requires Fortran. Adding to my last note: Another reason pythonmac.org/packages isn't getting the unmaintained it used to is the easy-install works for so many things. I think it's working fine for MPL now, for instance. Right. Since Leopard comes with setuptools, it seems like the mac-python community is being pushed towards using setuptools/EasyInstall instead of mpkg installers. I personally think that's a good thing. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] half a box?
+1 for adding this feature if it's not already available! On Feb 8, 2008 8:35 AM, Brian Blais [EMAIL PROTECTED] wrote: Hello, Is there an easy way to turn the box of an axis off, but only the top and right lines, keeping the bottom and left lines of the axis visible? I'd like to make a plot that has an x and y axis, but not a complete box around the data. thanks, Brian Blais -- Brian Blais [EMAIL PROTECTED] http://web.bryant.edu/~bblais - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] CocoaAgg backend status?
Michael, I'm sorry. I just realized I hadn't replied to you yet; sorry for the delay. John also pointed us to the transforms branch and that's where we'll start. Thanks! There's no real advantage to CoreAnimation per se (except eye candy), but going native for rendering would allow mpl to integrate more smoothly with the rest of the 2D and 3D (much of Quartz, and CoreImage the 2D rendering and filtering systems in OS X are actually rendered on the graphics card as OpenGL) rendering system in OS X. Some advantages, off the top of my head are resolution independence, ability to offload rendering and/or coordinate transformation to the graphics card, ability to easily produce output in any of the CoreImage supported formats, ability to incorporate transparency and alpha blending within the view hierarchy, ability to combine media (QuickTime, OpenGL, and Quartz) in layers (the real purpose of the CoreAnimation engine), ability to piggy back on improvements in Apple's rendering engine (things like anti-aliasing etc.), ColorSync support, and _maybe_ some speed improvements by taking a layer or two out of the rendering process. All of these are just speculation, at this time... we're just getting started but will share our results as soon as they're ready. barry On 12/5/07, Michael Droettboom [EMAIL PROTECTED] wrote: Barry Wark wrote: We (at my work) are just starting to think about writing a more direct Quartz backend for mpl. A native backend would let a matplotlib view participate in newer Cocoa technologies, such as resolution independence and CoreAnimation (it's possible with the current backend method, but not quite as flexible). I'm curious what Cocoa and CoreAnimation might enable... If you are looking into writing a Quartz rendering backend, you may want to start with the matplotlib transforms branch (which should become the trunk shortly, once the 0.91 release bugs get shaken out.) The number of methods that a backend writer must provide has been greatly reduced on that branch. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] TypeError on CocoaAgg backend
Chris, I appologize for cryptic language and quickly written emails leading you astray. I've included the diff of backend_cocoaagg.py (which has also been sent to the mpl devs) which seems to work for me. Barry backend_cocoaagg.py.diff Description: Binary data On Dec 3, 2007, at 8:00 PM, Chris Fonnesbeck wrote: On Dec 3, 2007 7:34 PM, Barry Wark [EMAIL PROTECTED] wrote: sorry instances of self.plotView.image On Dec 3, 2007 3:38 PM, Chris Fonnesbeck [EMAIL PROTECTED] wrote: I replaced the one instance of this that I found. I now get the following error: In [7]: show() --- ValueErrorTraceback (most recent call last) /Users/chris/ipython console in module() /Library/Python/2.5/site-packages/matplotlib/backends/ backend_cocoaagg.py in show() 44 def show(): 45 for manager in Gcf.get_all_fig_managers(): --- 46 manager.show() 47 48 def draw_if_interactive(): /Library/Python/2.5/site-packages/matplotlib/backends/ backend_cocoaagg.py in show(self) 203 mplBundle, 204 False) -- 205 NSApplication.sharedApplication().run() 206 207 ValueError: NSInvalidArgumentException - NSImageCell's object value must be an NSImage. -- Christopher J. Fonnesbeck + Fish Wildlife Research Institute (FWC) + 727.235.5570 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] CocoaAgg backend status?
Stephen, The CocoaAgg backend is not supported in IPython. You can use it in the non-interactive form (i.e. with a pylab.show() but you will have to close the window in order to return control to the IPython shell). It is possible to embed an MPL plot in a Cocoa application using the same trick as the CocoaAgg backend (rendering the plot using the Agg backend and then turning the rasterized bitmap into and NSBitmapImageRep and then displaying it in an NSImageView). I've posted previously about a py2app plugin which does just that and has an IB palette, but I haven't had time to update the IB palette to use the IB 3 plugin API yet. It uses Cocoa Bindings to provide data to the plot. I'm happy to send it to you as is, or you can wait until it's IB 3 ready. We (at my work) are just starting to think about writing a more direct Quartz backend for mpl. A native backend would let a matplotlib view participate in newer Cocoa technologies, such as resolution independence and CoreAnimation (it's possible with the current backend method, but not quite as flexible). This will make embedding easier, but will not solve the IPython issues. For now, one of the other backends, such as WXAgg or TkAgg is probably the better bet on OS X. barry On Dec 5, 2007, at 7:37 AM, Stephen Uhlhorn wrote: I was just wondering what the status of the CocoaAgg backend is since there is not much info available. Can it be used interactively w/ipython? Can it be used to embed mpl in a cocoa app and take advantage of all the xcode/interface builder stuff in OS X? Thanks- -stephen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-users mailing list [EMAIL PROTECTED] - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] power law fitting of data
Ping, You should investigate scipy.optimize.lsqFit for using least squares to fit an arbitrary function and scipy.odr for regular or orthogonal least squares fitting. barry On Dec 5, 2007 9:45 PM, Ping Yeh [EMAIL PROTECTED] wrote: Hi, I have (x,y) data that I want to fit to the formula y = a * x^b to determine a and b. How can I do it? The current manual only lists linear fit and polynomial fit. Or, putting it in a more general setting, is there a module to do fitting to an arbitrary function? It would be something like pars = fit(x, y, func) where func is a function like y = func(x, pars) with pars a 1-D array. Thanks, Ping - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] TypeError on CocoaAgg backend
sorry instances of self.plotView.image
On Dec 3, 2007 3:38 PM, Chris Fonnesbeck [EMAIL PROTECTED] wrote:
OK, I'm having a bad backend day (insert joke here).
Since I am on OSX, I decided to switch over to the CocoaAgg backend,
but it fails when trying to show a histogram, yielding the following
TypeError:
In [4]: from matplotlib import use
In [5]: use('CocoaAgg')
In [6]: from pylab import hist, show
In [7]: from numpy import random
In [8]: x = random.exponential(2, 1000)
In [9]: hist(x)
Out[9]:
(array([545, 230, 117, 59, 18, 15, 11, 1, 3, 1]),
array([ 2.99606603e-03, 1.52977050e+00, 3.05654494e+00,
4.58331937e+00, 6.11009381e+00, 7.63686824e+00,
9.16364268e+00, 1.06904171e+01, 1.22171915e+01,
1.37439660e+01]),
a list of 10 Patch objects)
In [10]: show()
---
TypeError Traceback (most recent call last)
/Users/chris/Projects/Occupancy-abundance Manuscript/ipython console
in module()
/Library/Python/2.5/site-packages/matplotlib/backends/backend_cocoaagg.py
in show()
44 def show():
45 for manager in Gcf.get_all_fig_managers():
--- 46 manager.show()
47
48 def draw_if_interactive():
/Library/Python/2.5/site-packages/matplotlib/backends/backend_cocoaagg.py
in show(self)
203 mplBundle,
204 False)
-- 205 NSApplication.sharedApplication().run()
206
207
/Library/Python/2.5/site-packages/matplotlib/backends/backend_cocoaagg.py
in startWithBundle_(self, bundle)
179 def startWithBundle_(self, bundle):
180 #NSApplicationLoad()
-- 181 if not
bundle.loadNibFile_externalNameTable_withZone_('Matplotlib.nib', {},
None):
182 print sys.stderr, 'Unable to load Matplotlib Cocoa UI!'
183 sys.exit()
/Library/Python/2.5/site-packages/matplotlib/backends/backend_cocoaagg.py
in awakeFromNib(self)
79
80 self.plotView.setImageFrameStyle_(NSImageFrameGroove)
--- 81 self.plotView.image = NSImage.alloc().initWithSize_((0,0))
82 self.plotView.setImage_(self.plotView.image)
83
TypeError: cannot change a method
--
Christopher J. Fonnesbeck
+ Fish Wildlife Research Institute (FWC)
+ 727.235.5570
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] [Numpy-discussion] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats
Matt, Yes, I agree. I wasn't coming at so much from the goal of making Pylab a Matlab clone (as you point out, that's silly, and misses much of the advantage of Python), but rather from the goal of making interactive use as efficient as possible. When I fire up ipython -pylab to do some quick exploration, it's nice not to have to type N.blah or pylab.plot etc. If I just import pylab *, however, then the commands I use may not be what I expect from more formal coding where I use N.blah numpy, S.foo for scipy, and pylab.bar for matplotlib. Making it easy for users to have either namespace strategy, with consistent bindings, ala the start of this thread is a good idea, IMO. Well, I've said my piece. I'll get out of the way and let others have a crack... Barry On 2/18/07, Matthew Brett [EMAIL PROTECTED] wrote: Hi, import plab plab.plot() #etc. and interactive use could do from plab import *. Yes... It's a hard call of course. I am a long term matlab user, and switched to python relatively recently. I do see the attraction of persuading people that you can get something very similar to matlab easily. The downside about making numpy / python like matlab is that you soon realize that you really have to think about your problems differently, and write code in a different way. I know that's obvious, but the variables as pointers, mutable / immutable types, zero based indexing, arrays vs matrices are all (fruitful) stumbling blocks. Then there is the very large change of thinking in an OO way, pulling in other large packages for doing other tasks, writing well-structured code with tests - all the features that python gives you for an industrial strength code base. And, the more pylab looks like matlab, the more surprised and confused people will be when they switch. So, I would argue that getting as close to matlab as possible should not be the unqualified goal here - it is a real change, with real pain, but great benefits. Best, Matthew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
