matplotlib-users Mailing List for matplotlib

Hi all,

I've been looking at matplotlib, as I'm using wxPyPlot and want a bit more...

Q1: Has anyone used matplotlib with Boa, and, as a Plug-in?

Q2: In the code below, (and with/from the example) I'm trying to simply 
display a plot, no toolbar, sizer etc.
The canvas appears on the panel, but no plot appears. What am I missing?

Python 2.2
WX 2.4

Thanks,
Ray


wxFrame1.py:
_____________________________________________________________
#Boa:Frame:wxFrame1

from wxPython.wx import *
from wxPyPlot.wxPyPlot import PlotCanvas

import numarray

import matplotlib
matplotlib.use('WX')
from matplotlib.backends.backend_wx import FigureCanvasWx
from matplotlib.figure import Figure
from matplotlib.axes import Subplot

def create(parent):
     return wxFrame1(parent)

[wxID_WXFRAME1, wxID_WXFRAME1PANEL1,
] = map(lambda _init_ctrls: wxNewId(), range(2))

class wxFrame1(wxFrame):
     def _init_ctrls(self, prnt):
         # generated method, don't edit
         wxFrame.__init__(self, id=wxID_WXFRAME1, name='', parent=prnt,
               pos=wxPoint(0, 0), size=wxSize(406, 341),
               style=wxDEFAULT_FRAME_STYLE, title="Test embedded wxFigure")

         self.panel1 = wxPanel(id=wxID_WXFRAME1PANEL1, name='panel1',
               parent=self, pos=wxPoint(0, 0), size=wxSize(398, 314),
               style=wxTAB_TRAVERSAL)

     def __init__(self, parent):
         self._init_ctrls(parent)
         self.fig = Figure((5,4), 75)
         self.canvas = FigureCanvasWx(self.panel1, -1, self.fig)
         self.plot_data()

     def plot_data(self):
         a = Subplot(self.fig, 111)

         t = numarray.arange(0.0,3.0,0.01)
         s = numarray.sin(2*numarray.pi*t)
         c = numarray.cos(2*numarray.pi*t)
         a.plot(t,s)
         a.plot(t,c)

Gregory Lielens wrote:
>>Except that z-order and a z coordinate really are different, so we 
>>shouldn't use z, it will make it harder, not easier to add 3-plots in 
>>the future!
> 
> Are they? I think not, cause in 3D you can not control the order of
> "painting", this is done so that elements which are in the background
> are hidden by elements which are more close to the observer...

sure, for data elements, but what about legends, error bars, etc?

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

> > > What is a
> > > good attribute name?  I think a method like scale_buoyancy would be
> > > useful too so users wouldn't have to know the default values.
> > 
> > zorder or layer
> 
> or height...

This is an excellent idea, but I'd suggest using the term 'depth'.
Then attributes with larger depth would be drawn below those with
smaller depth.

--Matt Newville <newville at cars.uchicago.edu>

On Mon, 2004-08-30 at 18:13, Chris Barker wrote:
> Gregory Lielens wrote:
> > I think this ordering is an excellent idea! In fact, I also prefer
> > zorder, or maybe height, or simply z: This can be seen as a
> > z-coordinate, whose only effect would be to change ordering for a 2D
> > plot, but could leads to 3D plots in the future :-)
> 
> Except that z-order and a z coordinate really are different, so we 
> shouldn't use z, it will make it harder, not easier to add 3-plots in 
> the future!

Are they? I think not, cause in 3D you can not control the order of
"painting", this is done so that elements which are in the background
are hidden by elements which are more close to the observer...
Having both a layer info and a z info in 3D would not be consistent
imho, painting at the end an element which should normally be hidden by
others seems like a hack for bypassing normal 3D rendering to me...
And if you use no perspective (infinite focal? ), a 3D plot watched from
above (Z=+inf) would be the same as a 2D plot with z=layer...In fact,
the painting from lower z to higher z is the basic 3D rendering
technique as far as I know...hum, except that the convention used in 3D
is z increasing means further away from the observer, so highest z =
first to be painted, which destroy my argument for "Large number printed
last", oups ;-)

Gregory Lielens wrote:
> I think this ordering is an excellent idea! In fact, I also prefer
> zorder, or maybe height, or simply z: This can be seen as a
> z-coordinate, whose only effect would be to change ordering for a 2D
> plot, but could leads to 3D plots in the future :-)

Except that z-order and a z coordinate really are different, so we 
shouldn't use z, it will make it harder, not easier to add 3-plots in 
the future!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hello,

I am trying to construct a plot that is a barchart with the X-axis being
dates.  I have used the plot_dates to generated line plots that look
great, however, other than turning the dates into integers myself I cannot
figure out a way to do a barchart with dates as the Xaxis.

Has anyone done one of these - I am using the wxPython backend, if that
matters.

Thanks!

Hubert Hickman

Hi,

I am a new user of matplotlib.
I have already plot some data whit it but, I can't find the way to control 
the axis scales ...
I know how to define the min/max number for each axis. Is it possible to 
define the intermediate scale values ??
For example , the x - axis marks are (automatically) choosen :0 , 0.2 , 0.4 
, 0.6 , 0.8 , 1.0
Can I have instead the values 0, 0.5 , 1.0 written on the axis ?

Best regards,
Xavier.

>>>>> "Jon" == Jon Peirce <Jon...@no...> writes:

    Jon> Hi there I just recently upgraded my copy of matplotlib to
    Jon> 0.61 (from 0.54!)  and have found a couple of my scripts no
    Jon> longer working. It seems that, for plot(), the argument
    Jon> markerfacecolor no longer takes a color triplet, but requires
    Jon> a string ('w', 'k' etc). markerEDGEcolor is still happy to
    Jon> take either form of color descriptor.

When you say, "no longer takes a color triplet" do you mean "causes an
error".  I tried an example and got an exception.  Simple fix: in
matplotlib/lines.py, at the top of the code import is_string_like from
matplotlib.cbook, ie,

from cbook import True, False, iterable, is_string_like

and at the end of the code, replace the _get_rgb_face method with

    def _get_rgb_face(self):
        if (self._markerfacecolor is None or
            (is_string_like(self._markerfacecolor) and
             self._markerfacecolor.lower()=='none') ): rgbFace = None
        else: rgbFace = colorConverter.to_rgb(self._markerfacecolor)
        return rgbFace

Thanks for letting me know,
JDH

>>>>> "Jon" == Jon Peirce <Jon...@no...> writes:

    Jon> On a different topic, imshow() only seems to display a single
    Jon> image at a time.  e.g. in the following example, when image2
    Jon> is drawn image1 is deleted.
    Jon> #------------------------------------------------- import
    Jon> matplotlib.matlab as mat myImage = mat.imread('image1.png')
    Jon> myImage2 = mat.imread('image2.png') mat.imshow(myImage,
    Jon> extent=[0,1,0,1]) mat.imshow(myImage2, extent=[1,2,1,2])
    Jon> mat.axis([0, 2, 0, 2]) mat.show()
    Jon> #------------------------------------------------- Is that a
    Jon> known issue? Is there a workaround?

    Jon> all the best, Jon

Ahh, interesting case.  I put the following line in the Axes.imshow
code to protect users from senselessly piling up lots of images

        if alpha==1: self._images = []

That is, I cleared the image stack if alpha was 1, reasoning you can't
see behind a fully opaque image; I was afraid someone might plot lots
of images to the same axes with alpha=1 , and never know they were
piling up images and hurting performance.  I had neglected to consider
that you might be using multiple images with different extents.

If you comment out that line in matplotlib/axes.py, your example will
work.

Note that I find it a bit more natural to define separate axes to hold
the separate images.  Of course, my approach won't work if you want to
plot other data, eg lines, that cover multiple images on the same
axes, but for simple montages, I think it's cleaner.

    import matplotlib.matlab as mat
    myImage = mat.imread('test1.png')
    myImage2 = mat.imread('test2.png')
    ax1 = mat.axes([0.5, 0.5, 0.5, 0.5])
    ax1.imshow(myImage)
    mat.axis('off')
    ax2 = mat.axes([0, 0.0, 0.5, 0.5])
    ax2.imshow(myImage2)
    mat.axis('off')
    mat.show()

JDH

Hi there

I just recently upgraded my copy of matplotlib to 0.61 (from 0.54!) and 
have found a couple of my scripts no longer working. It seems that, for 
plot(), the argument markerfacecolor no longer takes a color triplet, 
but requires a string ('w', 'k' etc). markerEDGEcolor is still happy to 
take either form of color descriptor.


On a different topic, imshow() only seems to display a single image at a 
time.
e.g. in the following example, when image2 is drawn image1 is deleted.
#-------------------------------------------------
import matplotlib.matlab as mat
myImage = mat.imread('image1.png')
myImage2 = mat.imread('image2.png')
mat.imshow(myImage, extent=[0,1,0,1])
mat.imshow(myImage2, extent=[1,2,1,2])
mat.axis([0, 2, 0, 2])
mat.show()
#-------------------------------------------------
Is that a known issue? Is there a workaround?

all the best,
Jon

This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Hi,

I think this ordering is an excellent idea! In fact, I also prefer
zorder, or maybe height, or simply z: This can be seen as a
z-coordinate, whose only effect would be to change ordering for a 2D
plot, but could leads to 3D plots in the future :-)

> > Should large numbers
> > be drawn last or first (last is my instinct, like list indexing, and
> > more efficient since you won't have to reverse the sort).
> 
> No preference.

Large number printed last, consistent with the zorder = 3rd coordinate
idea if one look the plot from above.

> > What is a
> > good attribute name?  I think a method like scale_buoyancy would be
> > useful too so users wouldn't have to know the default values.
> 
> zorder or layer

or height...


Best regards,

Greg.

Just some comments below as requested

----- Original Message -----
From: John Hunter <jdh...@ac...>

> Isn't this debatable?  Might someone want to see the errorbar range in
> front of or behind a large marker with transparency?  Why do you say
> this with certainty?

You're right John. Personally, I think the default order should be for ma=
rkers to be in front of errorbars, but on occasions I've wanted it the ot=
her way (the current implementation). I like your bouyancy idea. If you'r=
e after a different name, how about the more conventional "z-order".

> It's so easy to do that I could implement it faster than I can
> describe it, but I think buoyancy is a bad name (too hard to spell),
> and I wanted to get some feedback on the idea.  Should large numbers
> be drawn last or first (last is my instinct, like list indexing, and
> more efficient since you won't have to reverse the sort).

No preference.

> What is a
> good attribute name?  I think a method like scale_buoyancy would be
> useful too so users wouldn't have to know the default values.

zorder or layer

regards,
Gary
--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm