matplotlib-users — Discussion related to using matplotlib

Re: [Matplotlib-users] Bug in imshow ?

[Eric E. <ems...@ob...>]

Hi John,
first:  please enjoy your vacation! don't worry about the bugs and 
annoying emails,
I know this is not a hotline!!

As for the second question about the ''illegal'' axis position: in fact 
I would like
VERY much that you are allowed to have your plots outside the window.
I know this sounds strange, but it is indeed very useful to analyse data,
although I am not intending to produce a scientific plot with axes outside
the window of course...
At some point I could send you the small wrapper/functions I wrote to 
display images using
imshow where I put some more options like: scaling, maximum axis, 
offsets etc....
This would then show you what I am trying to reach and in fact could
lead to a very different solution (within matplotlib instead).

Eric

John Hunter wrote:

>>>>>>"Eric" == Eric Emsellem <ems...@ob...> writes:
>>>>>>            
>>>>>>
>
>    Eric> 1/ just to remind you that I am still looking for a solution
>    Eric> to the previously mentioned bug in imshow (in terms of
>    Eric> aspect='preserve').
>
>Hi Eric, thanks for the reminder.  Just to let you know, I'm away on
>vacation until next week.  Because I am staying with my sister in an
>apartment with an internet connection, I am tempted back to my old
>ways and occasionally respond on the list.  But for the more difficult
>questions and bugs, of which yours is one, which require more serious
>coding and testing, I'm deferring until I have a proper setup to work
>with.
>
>Rest assured that I have flagged these many emails and will pick them
>off as I can.
>
>Cheers,
>JDH
>
>  
>

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

Re: [Matplotlib-users] Bug in imshow ?

[John H. <jdh...@ac...>]

>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:

    Eric> 2/ I have another problem with imshow:

    Eric> When I do for example:

    Eric> figure(1) axes([-0.1,0,0.8,0.8]) myima = rand(50,50)
    Eric> imshow(myima)

    Eric> then it works and shows me the array with the axes partly
    Eric> outside the window since the origin for the X axis is < 0

Hmm, it never occurred to me that someone would be placing the axes
outside the figure!  You example appears to indicate that in the
imshow code I am missing a check somewhere for illegal y values but
getting it right for illegal x values.  My inclination is to disallow
axes borders outside the figure boundary.  Am I correct that you are
only driven to this extreme because you are trying to work around the
preserve bug?  If so, perhaps it will be an acceptable solution to
just fix that bug and raise an exception if someone uses left,bottom<0
or right,top>1.  


JDH

Re: [Matplotlib-users] Bug in imshow ?

[John H. <jdh...@ac...>]

>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:

    Eric> 1/ just to remind you that I am still looking for a solution
    Eric> to the previously mentioned bug in imshow (in terms of
    Eric> aspect='preserve').

Hi Eric, thanks for the reminder.  Just to let you know, I'm away on
vacation until next week.  Because I am staying with my sister in an
apartment with an internet connection, I am tempted back to my old
ways and occasionally respond on the list.  But for the more difficult
questions and bugs, of which yours is one, which require more serious
coding and testing, I'm deferring until I have a proper setup to work
with.

Rest assured that I have flagged these many emails and will pick them
off as I can.

Cheers,
JDH

Re: [Matplotlib-users] Luts in matplotlib ...

[Eric E. <ems...@ob...>]

Hi,

I think what you sent me may help although what you describe looks very much
like I have done in the piece of code I sent. It is not a first priority 
since what I wrote is
''kind of working'' (if I reload things everytime I display) but indeed 
an ''easy''
solution to this problem would be most welcome. The worry I have is that 
at the
moment we cannot load the lut without describing the datad keys and so on
so that it looks like a never ending story if people ask the developers 
everytime
to update the cm/colors files. (otherwise it crashes when you do imshow 
repeatedly)

As for the Question 3:

- I wish to load my array in LINEAR but then load a lut in LOG, so that 
the sampling of
the SAME lut is done but in LOG instead of LINEAR (so the fact that it 
is in log
would only appear when you load the color bar). This is used often when 
I need
to display a set of images side by side, some being in LIN, others in LOG.

My idea is the following:
- it is I think (may be wrong) feasible to add a functionality during 
the mapping of the lut
(when the LinearSegmented array is sampled on 256 levels) so that it 
takes the
LOG10, LN, EXP, or '-' (* -1 to invert a lut)  of the abscissa so that the
required effect appears. This would create a smashed lut, or an inverted 
one. etc...

See what I mean?

Eric

Perry Greenfield wrote:

>
> On Jan 11, 2005, at 10:25 AM, Eric Emsellem wrote:
>
>> HI again,
>>
>> I have questions of how to generate new LUTs outside matplotlib.
>>
>> 3 main issues:
>>
>> 1/ how to create a new lut in the same way that cm.py/colors.py is 
>> doing it
>>   in matplotlib
>> 2/ how to create a new lut which is given by a set of e.g., 256 
>> colours levels (R, G, B)
>>  but not as a segmented array as in cm/colors
>> 3/ How do you rescale a lut without rescaling the array itself?
>> (so an equivalent to load/itt log for example in Midas for those who 
>> know).
>>   For example I would like to use the jet lut but with a log increase
>>  of the lut so that e.g. displaying the color bar shows it is in ''log''
>>
>> For 1, I am not so sure what to do, and for 2/ I give below
>> what I am doing at the moment. To be frank, it looks quite ugly
>> (mainly because I am a bad programmer and don't know so much about
>> python/matplotlib).
>>
>> I got inspired by cm and colors.py and Midas lut
>> but really this is probably not the way to go.
>> In order to change the lut I just then do:
>>
>> lut('mylut')
>>
>> where 'mylut.lasc' is then the ascii file where the 256 colours are 
>> given in 3 columns
>> (R G B) of 256 rows
>>
>> The problem is that since I do not have the corresponding segmented 
>> array for each
>> lut (and I don't want it to be that way) I need to define a ''dummy'' 
>> array.
>> Then each time I use imshow I must reload the lut (otherwise it uses 
>> this dummy segmented
>> array which is here a gray lut).
>>
>> I am not sure this is all clear, but basically what I am trying to do 
>> here is to just
>> answer questions 1, 2, 3  above and below is an ugly solution for 2 
>> (but incomplete).
>>
>
> I think it is important to realize that you don't need to base it on 
> the existing colormapping mechanism, you just need to duplicate the 
> interface of colormaps, namely that it has N, and name attributes, and 
> that when the object is called with an array or scalar as an argument, 
> it will return the appropriate array (or tuple) as the result. How you 
> convert the array to rgba values is entirely up to you. But I think 
> there is enough similarity to what LinearSegmentColormap that 
> effectively its __call__ method can be resused without changed. You 
> would only override the __init__ to create the _red_lut,
> _green_lut, _blue_lut attribute directly from array arguments (if I 
> remember what MIDAS does; it's been nearly 20 years since I've used it!).
>
> That is something like this (untested, untried!)
>
> class ArrayColormap(LinearSegmentColormap):
>     """ really, it seems that linear should inherit from Array 
> instead!"""    def __init__(name, r,g,b):
>         """create color map from supplied r,g,b arrays"""
>         # put checks on r,g,b arrays here...
>         self._red_lut = r
>         self._green_lut = g
>         self._blue_lut = b
>         self.N = len(r)
>         self.name = name
>
> This is something we should add but you can try this in the meantime.
>
> The second part is how to set the lut to this. You can provide the new 
> colormap instance as a keyword (cmap) argument to imshow or figimage. 
> But I understand you would like a functional way to update an existing 
> display. There doesn't appear to be a function to do this, but a new 
> one is easily defined. Something like this ought to work (again 
> untested, and again, we should supply this in the next version)
>
> from
> def loadcm(cm):
>     """change the default colormap to cm"""
>     rc('image', cmap='yourcmname')
>     im = gci()
>     if im is not None:
>         im.set_cmap(cm)
>     draw_if_interactive()
>
> But the problem with this is that default mechanism won't work since 
> this eventually calls cm.get_cmap, which then looks for the named cm 
> in the cm.datad array to construct a LinearSegmentedColormap instance. 
> I think the solution here may need to have some sort of caching 
> mechanism so that user defined colormaps can be used as a default 
> (perhaps John can think of some other mechanism).
>
> I agree that it should be simple to define your own on the fly and be 
> able to use these. So we'll see how this is best handled.
>
> I'm not sure what you mean by 3. If you are changing the lut (i.e., 
> which colors map to which image intensity levels, the rescaling the 
> image is required when displaying it (in the "old days" when image 
> displays were only 8-bit and had hardware luts, one didn't have to do 
> that). If all you mean is that you already had transformed the data to 
> log format but want to show the lut as though the data were linearly 
> displayed, I suppose one would display a colorbar where the 
> intensities were suitably transformed from a linear ramp. But please 
> elaborate.
>
> Perry
>
>
>
>
>

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

Re: [Matplotlib-users] Luts in matplotlib ...

[Perry G. <pe...@st...>]

On Jan 11, 2005, at 10:25 AM, Eric Emsellem wrote:

> HI again,
>
> I have questions of how to generate new LUTs outside matplotlib.
>
> 3 main issues:
>
> 1/ how to create a new lut in the same way that cm.py/colors.py is 
> doing it
>   in matplotlib
> 2/ how to create a new lut which is given by a set of e.g., 256 
> colours levels (R, G, B)
>  but not as a segmented array as in cm/colors
> 3/ How do you rescale a lut without rescaling the array itself?
> (so an equivalent to load/itt log for example in Midas for those who 
> know).
>   For example I would like to use the jet lut but with a log increase
>  of the lut so that e.g. displaying the color bar shows it is in 
> ''log''
>
> For 1, I am not so sure what to do, and for 2/ I give below
> what I am doing at the moment. To be frank, it looks quite ugly
> (mainly because I am a bad programmer and don't know so much about
> python/matplotlib).
>
> I got inspired by cm and colors.py and Midas lut
> but really this is probably not the way to go.
> In order to change the lut I just then do:
>
> lut('mylut')
>
> where 'mylut.lasc' is then the ascii file where the 256 colours are 
> given in 3 columns
> (R G B) of 256 rows
>
> The problem is that since I do not have the corresponding segmented 
> array for each
> lut (and I don't want it to be that way) I need to define a ''dummy'' 
> array.
> Then each time I use imshow I must reload the lut (otherwise it uses 
> this dummy segmented
> array which is here a gray lut).
>
> I am not sure this is all clear, but basically what I am trying to do 
> here is to just
> answer questions 1, 2, 3  above and below is an ugly solution for 2 
> (but incomplete).
>

I think it is important to realize that you don't need to base it on 
the existing colormapping mechanism, you just need to duplicate the 
interface of colormaps, namely that it has N, and name attributes, and 
that when the object is called with an array or scalar as an argument, 
it will return the appropriate array (or tuple) as the result. How you 
convert the array to rgba values is entirely up to you. But I think 
there is enough similarity to what LinearSegmentColormap that 
effectively its __call__ method can be resused without changed. You 
would only override the __init__ to create the _red_lut,
_green_lut, _blue_lut attribute directly from array arguments (if I 
remember what MIDAS does; it's been nearly 20 years since I've used 
it!).

That is something like this (untested, untried!)

class ArrayColormap(LinearSegmentColormap):
	""" really, it seems that linear should inherit from Array 
instead!"""	def __init__(name, r,g,b):
		"""create color map from supplied r,g,b arrays"""
         # put checks on r,g,b arrays here...
         self._red_lut = r
         self._green_lut = g
         self._blue_lut = b
         self.N = len(r)
         self.name = name

This is something we should add but you can try this in the meantime.

The second part is how to set the lut to this. You can provide the new 
colormap instance as a keyword (cmap) argument to imshow or figimage. 
But I understand you would like a functional way to update an existing 
display. There doesn't appear to be a function to do this, but a new 
one is easily defined. Something like this ought to work (again 
untested, and again, we should supply this in the next version)

from
def loadcm(cm):
     """change the default colormap to cm"""
     rc('image', cmap='yourcmname')
     im = gci()
     if im is not None:
         im.set_cmap(cm)
     draw_if_interactive()

But the problem with this is that default mechanism won't work since 
this eventually calls cm.get_cmap, which then looks for the named cm in 
the cm.datad array to construct a LinearSegmentedColormap instance. I 
think the solution here may need to have some sort of caching mechanism 
so that user defined colormaps can be used as a default (perhaps John 
can think of some other mechanism).

I agree that it should be simple to define your own on the fly and be 
able to use these. So we'll see how this is best handled.

I'm not sure what you mean by 3. If you are changing the lut (i.e., 
which colors map to which image intensity levels, the rescaling the 
image is required when displaying it (in the "old days" when image 
displays were only 8-bit and had hardware luts, one didn't have to do 
that). If all you mean is that you already had transformed the data to 
log format but want to show the lut as though the data were linearly 
displayed, I suppose one would display a colorbar where the intensities 
were suitably transformed from a linear ramp. But please elaborate.

Perry

Re: [Matplotlib-users] IDLE hangs despite -n

[Hans F. <H.F...@so...>]

John,

>>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
>
>    Hans> Hm. Done that. A figure window pops up immediately but is
>    Hans> not being updated correctly: a part of the graph is visible,
>    Hans> the other part of the figure (which was underneath another
>    Hans> window initially) appears white. The titel of the figure
>    Hans> says "Figure 1 (Not responding)".  IDLE, however, responds
>    Hans> happily ;-) T
>
> Todd, many moons ago you wrote me and said I had inadvertently screwed
> up something in tkagg show that broke the idle -n behavior.  If I
> recall correctly, we never reverted, since I didn't understand exactly
> what to do.  Perhaps you could revisit the current tkagg versus the
> old one to make sure it is right.
>
> Hans, does it make a difference if you uncomment
>
>    #os.environ['PYTHONINSPECT'] = '1'
>
> in the show method of
> site-packages/matplotlib/backends/backend_tkagg.py? You should set
> 'interactive : True' as Todd suggested.  Do not use show, as it is not
> designed for interactive use.  I suggest carefully testing all 4
> combinations: with and without the PYTHONINSPECTmline, and with and
> without -n.

Setting 'interactive=True' in .matplotlibrc

IDLE           #os.environ['PYTHONINSPECT'] = '1'        -> fail
IDLE -n        #os.environ['PYTHONINSPECT'] = '1'        -> fail
IDLE           os.environ['PYTHONINSPECT'] = '1'         -> fail
IDLE -n        os.environ['PYTHONINSPECT'] = '1'         -> success

So that's good. However, notice that also

setting 'interactive=False'

IDLE           os.environ['PYTHONINSPECT'] = '1'

seems to work! (Which is what I wanted initially and what didn't work.)


So from my naive perspective the line "environ['PYTHONINSPECT'] = '1'  " 
should not be commented.

Thanks for you help -- hope this is useful,

Hans

Re: [Matplotlib-users] IDLE hangs despite -n

[Todd M. <jm...@st...>]

On Tue, 2005-01-11 at 16:17, Hans Fangohr wrote:
> Hi Todd,
> 
> thanks for the quick response.
> 
> > I just tried this out and found that setting "interactive" to "True" in
> > C:\python23\share\matplotlib\.matplotlibrc obviated the need to use the
> > show() command.  The plot then comes up as soon as you issue the plot()
> > command.
> Hm. Done that. A figure window pops up immediately but is not being 
> updated correctly: a part of the graph is visible, the other part of the 
> figure (which was underneath another window initially) appears white. The 
> titel of the figure says "Figure 1 (Not responding)".
> IDLE, however, responds happily ;-) T
> 
> > Multiple plotting-closing cycles worked fine in the same Idle
> > session.
> Good -- so this works at your machine, not at mine. The strange thing is 
> that I installed WinXP from scratch just a few days ago on that machine, 
> so it should be a fairly 'clean' environment.
> 
> I take it there is no more recent version of matplotlib for windows 
> (and Python 2.3) than 0.70.1?

No.  Just to be clear:  I set interactive to True, and used "idle -n"
from Python-2.3.4 and it worked fine for me on Windows 2000 Pro.  Idle
should be reporting "No Subprocess" when it starts up.

Regards,
Todd

> Thanks,
> 
> Hans
> 
> 
> >
> > Regards,
> > Todd
> >
> > On Tue, 2005-01-11 at 14:29, Hans Fangohr wrote:
> >> Dear all,
> >>
> >> I tried to make matplotlib work with IDLE on Windows. I have settled for
> >> the Enthough Python Edition and the latest matplotlib (both executables
> >> can be found in www.soton.ac.uk/~fangohr/download/python).
> >>
> >> I have prepared the exercises on linux and am now trying to run them in
> >> windows. This is where I realised that matplotlib doesn't work well with
> >> IDLE.
> >>
> >> More particularly, it is known that the default backend TkAgg doesn't work
> >> with IDLE (see here http://matplotlib.sourceforge.net/backends.html#TkAgg)
> >> but it appears to work with "IDLE -n" (as it says on that web page).
> >>
> >> The problem I experience is this:
> >>
> >> -start idle
> >> -execute these commands:
> >>
> >>    import pylab
> >>    pylab.plot(range(10))
> >>    pylab.show()
> >>
> >> This produces a figure window which seems to work fine.
> >>
> >> At this point when closing the figure window, I can't get the IDLE
> >> prompt active again. (It seems that IDLE thinks the program and the figure
> >> process are still running, and is waiting for control to return.)
> >>
> >> This, in itself, is maybe not suprising. However, the idle -n switch
> >> doesn't seem to solve the problem for me (see below).
> >>
> >> The same problem is observed when I execute a program in the IDLE editor
> >> (by pressing F5).
> >>
> >> Maybe this is the problem:
> >>
> >> I have tried to tell IDLE to start with the "-n" by modifying the properties for the
> >> IDLE link in the start menu from
> >>
> >> C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"
> >>
> >> to
> >>
> >> C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw" "-n"
> >>
> >> but this doesn't seem to solve the problem: I get exactly the same
> >> behaviour as described above. Am I doing the right thing?
> >>
> >> Can anyone give me some advice?
> >>
> >> Many thanks,
> >>
> >> Hans
> >>
> >>
> >> P.S. Funnily enough, there are two Windows machines with a very similar
> >> software setup, i.e. enthought python plus matplotlib, where the default
> >> TkAgg interface seems to work happily togethe with IDLE. Unfortunately,
> >> these are not the ones I am trying to get to work :-|
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------
> >> Dr Hans Fangohr
> >>
> >> Computational Engineering & Design Research Group
> >> School of Engineering Sciences
> >> University of Southampton
> >> Southampton, SO17 1BJ
> >> United Kingdom
> >>
> >> Location: Building 25, Room 1027
> >> phone : +44 (0) 23 8059 8345
> >> fax   : +44 (0) 23 8059 7082
> >> email : fa...@so...
> >> -------------------------------------------------
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> The SF.Net email is sponsored by: Beat the post-holiday blues
> >> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> >> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > -- 
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> 
> -------------------------------------------------
> Dr Hans Fangohr
> 
> Computational Engineering & Design Research Group
> School of Engineering Sciences
> University of Southampton
> Southampton, SO17 1BJ
> United Kingdom
> 
> Location: Building 25, Room 1027
> phone : +44 (0) 23 8059 8345
> fax   : +44 (0) 23 8059 7082
> email : fa...@so...
> -------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 

Re: [Matplotlib-users] IDLE hangs despite -n

[John H. <jdh...@ac...>]

>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:

    Hans> Hm. Done that. A figure window pops up immediately but is
    Hans> not being updated correctly: a part of the graph is visible,
    Hans> the other part of the figure (which was underneath another
    Hans> window initially) appears white. The titel of the figure
    Hans> says "Figure 1 (Not responding)".  IDLE, however, responds
    Hans> happily ;-) T

Todd, many moons ago you wrote me and said I had inadvertently screwed
up something in tkagg show that broke the idle -n behavior.  If I
recall correctly, we never reverted, since I didn't understand exactly
what to do.  Perhaps you could revisit the current tkagg versus the
old one to make sure it is right.

Hans, does it make a difference if you uncomment

    #os.environ['PYTHONINSPECT'] = '1'

in the show method of
site-packages/matplotlib/backends/backend_tkagg.py? You should set
'interactive : True' as Todd suggested.  Do not use show, as it is not
designed for interactive use.  I suggest carefully testing all 4
combinations: with and without the PYTHONINSPECTmline, and with and
without -n.  As you probably know, you'll need to restart idle after
every change to the module source code, or at least reload the module
if you know how to do that.

Some bugs refuse to die.  Let us know...


    Hans> I take it there is no more recent version of matplotlib for
    Hans> windows (and Python 2.3) than 0.70.1?

That's the latest.

Good luck!
JDH

Re: [Matplotlib-users] IDLE hangs despite -n

[Hans F. <H.F...@so...>]

Hi Todd,

thanks for the quick response.

> I just tried this out and found that setting "interactive" to "True" in
> C:\python23\share\matplotlib\.matplotlibrc obviated the need to use the
> show() command.  The plot then comes up as soon as you issue the plot()
> command.
Hm. Done that. A figure window pops up immediately but is not being 
updated correctly: a part of the graph is visible, the other part of the 
figure (which was underneath another window initially) appears white. The 
titel of the figure says "Figure 1 (Not responding)".
IDLE, however, responds happily ;-) T

> Multiple plotting-closing cycles worked fine in the same Idle
> session.
Good -- so this works at your machine, not at mine. The strange thing is 
that I installed WinXP from scratch just a few days ago on that machine, 
so it should be a fairly 'clean' environment.

I take it there is no more recent version of matplotlib for windows 
(and Python 2.3) than 0.70.1?

Thanks,

Hans


>
> Regards,
> Todd
>
> On Tue, 2005-01-11 at 14:29, Hans Fangohr wrote:
>> Dear all,
>>
>> I tried to make matplotlib work with IDLE on Windows. I have settled for
>> the Enthough Python Edition and the latest matplotlib (both executables
>> can be found in www.soton.ac.uk/~fangohr/download/python).
>>
>> I have prepared the exercises on linux and am now trying to run them in
>> windows. This is where I realised that matplotlib doesn't work well with
>> IDLE.
>>
>> More particularly, it is known that the default backend TkAgg doesn't work
>> with IDLE (see here http://matplotlib.sourceforge.net/backends.html#TkAgg)
>> but it appears to work with "IDLE -n" (as it says on that web page).
>>
>> The problem I experience is this:
>>
>> -start idle
>> -execute these commands:
>>
>>    import pylab
>>    pylab.plot(range(10))
>>    pylab.show()
>>
>> This produces a figure window which seems to work fine.
>>
>> At this point when closing the figure window, I can't get the IDLE
>> prompt active again. (It seems that IDLE thinks the program and the figure
>> process are still running, and is waiting for control to return.)
>>
>> This, in itself, is maybe not suprising. However, the idle -n switch
>> doesn't seem to solve the problem for me (see below).
>>
>> The same problem is observed when I execute a program in the IDLE editor
>> (by pressing F5).
>>
>> Maybe this is the problem:
>>
>> I have tried to tell IDLE to start with the "-n" by modifying the properties for the
>> IDLE link in the start menu from
>>
>> C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"
>>
>> to
>>
>> C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw" "-n"
>>
>> but this doesn't seem to solve the problem: I get exactly the same
>> behaviour as described above. Am I doing the right thing?
>>
>> Can anyone give me some advice?
>>
>> Many thanks,
>>
>> Hans
>>
>>
>> P.S. Funnily enough, there are two Windows machines with a very similar
>> software setup, i.e. enthought python plus matplotlib, where the default
>> TkAgg interface seems to work happily togethe with IDLE. Unfortunately,
>> these are not the ones I am trying to get to work :-|
>>
>>
>>
>>
>>
>> -------------------------------------------------
>> Dr Hans Fangohr
>>
>> Computational Engineering & Design Research Group
>> School of Engineering Sciences
>> University of Southampton
>> Southampton, SO17 1BJ
>> United Kingdom
>>
>> Location: Building 25, Room 1027
>> phone : +44 (0) 23 8059 8345
>> fax   : +44 (0) 23 8059 7082
>> email : fa...@so...
>> -------------------------------------------------
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> -- 
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

-------------------------------------------------
Dr Hans Fangohr

Computational Engineering & Design Research Group
School of Engineering Sciences
University of Southampton
Southampton, SO17 1BJ
United Kingdom

Location: Building 25, Room 1027
phone : +44 (0) 23 8059 8345
fax   : +44 (0) 23 8059 7082
email : fa...@so...
-------------------------------------------------

Re: [Matplotlib-users] IDLE hangs despite -n

[Todd M. <jm...@st...>]

Hi Hans,

I just tried this out and found that setting "interactive" to "True" in
C:\python23\share\matplotlib\.matplotlibrc obviated the need to use the
show() command.  The plot then comes up as soon as you issue the plot()
command.  Multiple plotting-closing cycles worked fine in the same Idle
session.

Regards,
Todd

On Tue, 2005-01-11 at 14:29, Hans Fangohr wrote:
> Dear all,
> 
> I tried to make matplotlib work with IDLE on Windows. I have settled for 
> the Enthough Python Edition and the latest matplotlib (both executables 
> can be found in www.soton.ac.uk/~fangohr/download/python).
> 
> I have prepared the exercises on linux and am now trying to run them in
> windows. This is where I realised that matplotlib doesn't work well with
> IDLE.
> 
> More particularly, it is known that the default backend TkAgg doesn't work
> with IDLE (see here http://matplotlib.sourceforge.net/backends.html#TkAgg)
> but it appears to work with "IDLE -n" (as it says on that web page).
> 
> The problem I experience is this:
> 
> -start idle
> -execute these commands:
> 
>    import pylab
>    pylab.plot(range(10))
>    pylab.show()
> 
> This produces a figure window which seems to work fine.
> 
> At this point when closing the figure window, I can't get the IDLE
> prompt active again. (It seems that IDLE thinks the program and the figure
> process are still running, and is waiting for control to return.)
> 
> This, in itself, is maybe not suprising. However, the idle -n switch
> doesn't seem to solve the problem for me (see below).
> 
> The same problem is observed when I execute a program in the IDLE editor
> (by pressing F5).
> 
> Maybe this is the problem:
> 
> I have tried to tell IDLE to start with the "-n" by modifying the properties for the
> IDLE link in the start menu from
> 
> C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"
> 
> to
> 
> C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw" "-n"
> 
> but this doesn't seem to solve the problem: I get exactly the same
> behaviour as described above. Am I doing the right thing?
> 
> Can anyone give me some advice?
> 
> Many thanks,
> 
> Hans
> 
> 
> P.S. Funnily enough, there are two Windows machines with a very similar 
> software setup, i.e. enthought python plus matplotlib, where the default 
> TkAgg interface seems to work happily togethe with IDLE. Unfortunately, 
> these are not the ones I am trying to get to work :-|
> 
> 
> 
> 
> 
> -------------------------------------------------
> Dr Hans Fangohr
> 
> Computational Engineering & Design Research Group
> School of Engineering Sciences
> University of Southampton
> Southampton, SO17 1BJ
> United Kingdom
> 
> Location: Building 25, Room 1027
> phone : +44 (0) 23 8059 8345
> fax   : +44 (0) 23 8059 7082
> email : fa...@so...
> -------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 

[Matplotlib-users] IDLE hangs despite -n

[Hans F. <H.F...@so...>]

Dear all,

I tried to make matplotlib work with IDLE on Windows. I have settled for 
the Enthough Python Edition and the latest matplotlib (both executables 
can be found in www.soton.ac.uk/~fangohr/download/python).

I have prepared the exercises on linux and am now trying to run them in
windows. This is where I realised that matplotlib doesn't work well with
IDLE.

More particularly, it is known that the default backend TkAgg doesn't work
with IDLE (see here http://matplotlib.sourceforge.net/backends.html#TkAgg)
but it appears to work with "IDLE -n" (as it says on that web page).

The problem I experience is this:

-start idle
-execute these commands:

   import pylab
   pylab.plot(range(10))
   pylab.show()

This produces a figure window which seems to work fine.

At this point when closing the figure window, I can't get the IDLE
prompt active again. (It seems that IDLE thinks the program and the figure
process are still running, and is waiting for control to return.)

This, in itself, is maybe not suprising. However, the idle -n switch
doesn't seem to solve the problem for me (see below).

The same problem is observed when I execute a program in the IDLE editor
(by pressing F5).

Maybe this is the problem:

I have tried to tell IDLE to start with the "-n" by modifying the properties for the
IDLE link in the start menu from

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

to

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw" "-n"

but this doesn't seem to solve the problem: I get exactly the same
behaviour as described above. Am I doing the right thing?

Can anyone give me some advice?

Many thanks,

Hans


P.S. Funnily enough, there are two Windows machines with a very similar 
software setup, i.e. enthought python plus matplotlib, where the default 
TkAgg interface seems to work happily togethe with IDLE. Unfortunately, 
these are not the ones I am trying to get to work :-|





-------------------------------------------------
Dr Hans Fangohr

Computational Engineering & Design Research Group
School of Engineering Sciences
University of Southampton
Southampton, SO17 1BJ
United Kingdom

Location: Building 25, Room 1027
phone : +44 (0) 23 8059 8345
fax   : +44 (0) 23 8059 7082
email : fa...@so...
-------------------------------------------------

Re: AW: [Matplotlib-users] French characters

[Matt N. <new...@ca...>]

Hi,

> thank you for your hints. If I understand you right,
> Matlibplot should be able to display the french characters and
> there is no need for \acute etc. 

Sorry for the confusion, that's not what I meant.  I think that
the acute sign would have to be added to the list of symbols that
mathtext can handle.  That would probably mean both special code
in mathtext.py and an entry in _mathtext_data.py. I'm not sure
what the right entry in the font table would be, as I don't
understand the entries in the latex_to_bakoma dictionary in
_mathtext_data.py at all.

--Matt

Re: [Matplotlib-users] Bug in imshow ?

[Xavier G. <gn...@ob...>]

Eric Emsellem a écrit :

> Hi,
>
> 2 issues:
>
> 1/ just to remind you that I am still looking for a solution to the 
> previously
> mentioned bug in imshow (in terms of aspect='preserve').
>
> 2/ I have another problem with imshow:
>
> When I do for example:
>
> figure(1)
> axes([-0.1,0,0.8,0.8])
> myima = rand(50,50)
> imshow(myima)
>
> then it works and shows me the array with the axes partly outside the 
> window
> since the origin for the X axis is < 0
>
> However if I do:
>
> figure(1)
> axes([0,-0.1,0.8,0.8])
> myima = rand(50,50)
> imshow(myima)
>
> with this time the Y origin < 0:
>
> then I get a SEGMENTATION FAULT
>
> ??
> thanks for any help there...
>
> Eric
>
I reproduce this bug with GTK and TKagg.

With DEBUG = 1  I get this (may help):

axes([0,-0.1,0.8,0.8])
myima = rand(50,50)
In [5]: imshow(myima)

FigureCanvasGTKAgg.draw
Segmentation fault

Xavier

AW: [Matplotlib-users] French characters

[Mayer G. <ger...@co...>]

Dear Matt,
thank you for your hints. If I understand you right, Matlibplot should =
be able to display the french characters and there is no need for \acute =
etc. That's interesting and I would appreciate it. However e.g. =
title('Temp=E9rature') does not work properly. Instead of =E9 I see a =
rectangle on the screen. May be something is wrong with my installation?
Regards
Gerhard

-----Urspr=FCngliche Nachricht-----
Von: Matt Newville [mailto:new...@ca...]=20
Gesendet: Dienstag, 11. Januar 2005 18:03
An: mat...@li...; Mayer Gerhard
Betreff: Re: [Matplotlib-users] French characters


I think you'd have to add \acute to the overunder dictionary in =
mathtext.py and then use as '\acute{e}'.  That assumes that a "`"
is close enough for the accent mark.  If so, it's possible that other =
accent marks as well, though I don't see how to get an umlaut or =
cedilla.

As a general question, can mathtext directly access characters in the =
TeX font tables?  Would that simply involve adding more entries to =
latex_to_bakoma in _mathtext_data.py???  If so, that might make it =
easier to reproduce many of the TeX accents (including umlaut), as the =
double-dot and acute marks have actual places in the font tables.  It =
migh also make \AA (\Angstrom) less of a corner case.

--Matt

On Tue, 11 Jan 2005, Mayer Gerhard wrote:

> Hi all,
> I cannot figure out howto use french characters using the Agg backend. =

> E.g. title(r'$Temp \acute e rature$') does not work.
> Has anyone an idea howto do it?
> Gerhard
>=20
>=20

Re: [Matplotlib-users] French characters

[Matt N. <new...@ca...>]

I think you'd have to add \acute to the overunder dictionary in
mathtext.py and then use as '\acute{e}'.  That assumes that a "`"
is close enough for the accent mark.  If so, it's possible that
other accent marks as well, though I don't see how to get an
umlaut or cedilla.

As a general question, can mathtext directly access characters in
the TeX font tables?  Would that simply involve adding more
entries to latex_to_bakoma in _mathtext_data.py???  If so, that
might make it easier to reproduce many of the TeX accents
(including umlaut), as the double-dot and acute marks have actual
places in the font tables.  It migh also make \AA (\Angstrom) less
of a corner case.

--Matt

On Tue, 11 Jan 2005, Mayer Gerhard wrote:

> Hi all,
> I cannot figure out howto use french characters using the Agg backend. 
> E.g. title(r'$Temp \acute e rature$') does not work.
> Has anyone an idea howto do it?
> Gerhard
> 
> 

[Matplotlib-users] Luts in matplotlib ...

[Eric E. <ems...@ob...>]

HI again,

I have questions of how to generate new LUTs outside matplotlib.

3 main issues:

1/ how to create a new lut in the same way that cm.py/colors.py is doing it
   in matplotlib
2/ how to create a new lut which is given by a set of e.g., 256 colours 
levels (R, G, B)
  but not as a segmented array as in cm/colors
3/ How do you rescale a lut without rescaling the array itself?
(so an equivalent to load/itt log for example in Midas for those who know).
   For example I would like to use the jet lut but with a log increase
  of the lut so that e.g. displaying the color bar shows it is in ''log''

For 1, I am not so sure what to do, and for 2/ I give below
what I am doing at the moment. To be frank, it looks quite ugly
(mainly because I am a bad programmer and don't know so much about
python/matplotlib).

I got inspired by cm and colors.py and Midas lut
but really this is probably not the way to go.
In order to change the lut I just then do:

lut('mylut')

where 'mylut.lasc' is then the ascii file where the 256 colours are 
given in 3 columns
(R G B) of 256 rows

The problem is that since I do not have the corresponding segmented 
array for each
lut (and I don't want it to be that way) I need to define a ''dummy'' array.
Then each time I use imshow I must reload the lut (otherwise it uses 
this dummy segmented
array which is here a gray lut).

I am not sure this is all clear, but basically what I am trying to do 
here is to just
answer questions 1, 2, 3  above and below is an ugly solution for 2 (but 
incomplete).

Any help is welcome. Thanks.

Eric
#########################################################################################
"""######################################
   # MIDAS-LIKE LUT and ITT ??
   ######################################"""
_dummy_data =  {'red':   ((0., 0, 0), (1., 1, 1)),
               'green': ((0., 0, 0), (1., 1, 1)),
               'blue':  ((0., 0, 0), (1., 1, 1))}

class myMidasLut(colors.LinearSegmentedColormap):
   """   Definition of luts a la Midas, with R, G, and B levels
   """
   def __init__(self, name='grey', alpha=1.0):
      self.LUT_PATH = '/softwares/python/pycral/midaslut/'
      self._red_lut = arange(256)/255.
      self._green_lut = arange(256)/255.
      self._blue_lut = arange(256)/255.
      self._isinit = True
      self.name = name
      self.N = 256
      cm.datad[name] = _dummy_data

   def new(self,name, alpha=1.0):  
      sname = str(name)
      sname = self.LUT_PATH+sname+".lasc"
      if os.path.isfile(sname):
         f = open(sname)
         list = f.readlines()
         for i in range(256):
            self._red_lut[i] = float(list[i].split()[0])
            self._green_lut[i] = float(list[i].split()[1])
            self._blue_lut[i] = float(list[i].split()[2])
         f.close
         self.name = name
      else :
         print 'ERROR: Lut file', name,'does not exist'

      rc('image', cmap=name)
      im = gci()
      if im is not None:
         im.set_cmap(self)
         im.set_alpha(alpha)
         draw_if_interactive()

      cm.datad[name] = _dummy_data
   
################ Default Lut initialisation ##
pglut = myMidasLut()

################ Function to change the lut ##
def lut (name, alpha=1.0) :
   pglut.new(name, alpha)

#########################################################################################

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

[Matplotlib-users] Bug in imshow ?

[Eric E. <ems...@ob...>]

Hi,

2 issues:

1/ just to remind you that I am still looking for a solution to the 
previously
mentioned bug in imshow (in terms of aspect='preserve').

2/ I have another problem with imshow:

When I do for example:

figure(1)
axes([-0.1,0,0.8,0.8])
myima = rand(50,50)
imshow(myima)

then it works and shows me the array with the axes partly outside the window
since the origin for the X axis is < 0

However if I do:

figure(1)
axes([0,-0.1,0.8,0.8])
myima = rand(50,50)
 imshow(myima)

with this time the Y origin < 0:

then I get a SEGMENTATION FAULT

??
thanks for any help there...

Eric

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

Re: [Matplotlib-users] Possible bug in imshow?

[John H. <jdh...@ac...>]

>>>>> "James" == James Boyle <bo...@ll...> writes:

    James> if I run: PL.imshow(TArm,cmap = ML.cm.winter )
    James> PL.colorbar()

    James> I get the error listed at the end of this message:

Hi Jim,

What version of mpl are you using?  With 0.70.1 I see no problems

    >>> from pylab import *
    >>> x = rand(12,12)
    >>> imshow(x, cmap=cm.winter)
    <matplotlib.image.AxesImage instance at 0x01476DC8>
    >>> colorbar()
    <matplotlib.axes.Axes instance at 0x01476EB8>

I did fix some colorbar bugs in 0.65.1.  If your version is older than
this, it may explain the problem.

If you are using 0.70.1, please provide a little more information
about your environment, specifically a complete test script run with
the output of --verbose-helpful.

Hope this helps,
JDH

[Matplotlib-users] French characters

[Mayer G. <ger...@co...>]

Hi all,
I cannot figure out howto use french characters using the Agg backend.=20
E.g. title(r'$Temp \acute e rature$') does not work.
Has anyone an idea howto do it?
Gerhard

[Matplotlib-users] Possible bug in imshow?

[James B. <bo...@ll...>]

if I run:

PL.imshow(TArm,cmap = ML.cm.winter )
PL.colorbar()

I get the error listed at the end of this message:

However if I run:
PL.imshow(TArm,cmap = ML.cm.winter,vmin=-50.,vmax=50.)
PL.colorbar()

Then all goes as expected - from where the code goes astray, it appears  
as if the autoscale limits are not being set???which is
circumvented if a specify the max and min explicitly.

Is this a problem? or am I missing something?

--Jim


/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/matplotlib/pylab.py in colorbar(tickfmt)
     597     N = 200
     598
--> 599     c = linspace(cmin, cmax, N)
     600     C = array([c,c])
     601

/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/matplotlib/mlab.py in linspace(xmin, xmax, N)
      73 def linspace(xmin, xmax, N):
      74    if N==1: return xmax
---> 75    dx = (xmax-xmin)/(N-1)
      76    return xmin + dx*arange(N)
      77

TypeError: unsupported operand type(s) for /: 'array' and 'int'

Re: [Matplotlib-users] matplotlib / Python 2.4 / Numarray

[Greg W. <gvw...@cs...>]

Thanks very much, Gary; that fixed it right off the bat.

Thanks,
Greg

On Mon, 10 Jan 2005, Gary Ruben wrote:

> Another piece of info:
> Jonathan Brandmeyer on the numpy discussion list has built a version of
> Numeric for Python 2.4 and is temporarily hosting it until an official
> build is done. It's version 23.6 which is only 0.1 older than 23.7
> (according to my hp calculator):
> http://www4.ncsu.edu/~jdbrandm/Numeric-23.6.win32-py2.4.exe
>
> Gary R.

[Matplotlib-users] Bug? in zoom with TkAgg backend

[Xavier G. <gn...@ob...>]

Hi,

TkAgg backend works fine except a corner case with the zoom button.

Consider with simple code :

from pylab import *
A = rand(1000,1000)
imshow(A,interpolation=Nearest)

When I zoom 3 or 4 times on the resulting image using the backend zoom 
button, I get an all white image from a certain zoom level (i.e. from 
factor of 100).

It is clearly a corner case but I sometime have to zoom on very fine 
details.

Consider this code in backend_bases.py :

 lastx, lasty, a, ind, lim, trans = self._xypress
        # ignore singular clicks - 5 pixels is a threshold
        if abs(x-lastx)<5 or abs(y-lasty)<5:
            self._xypress = None
            self.release(event)
            self.draw()
            return

I think we could decrease the threshold down to 1 pixel. Please tell me 
if it is incompatible with another piece of code.

Selecting a less than 1*1 (or 2*2) pixels area should do nothing (and 
not produce a blank image).

Cheers,
Xavier.

Re: [Matplotlib-users] matplotlib / Python 2.4 / Numarray

[Gary R. <ga...@em...>]

Another piece of info:
Jonathan Brandmeyer on the numpy discussion list has built a version of Num=
eric for Python 2.4 and is temporarily hosting it until an official build i=
s done. It's version 23.6 which is only 0.1 older than 23.7 (according to m=
y hp calculator):
http://www4.ncsu.edu/~jdbrandm/Numeric-23.6.win32-py2.4.exe

Gary R.

----- Original Message -----
From: "Greg Wilson" <gvw...@cs...>
To: mat...@li...
Subject: [Matplotlib-users] matplotlib / Python 2.4 / Numarray
Date: Sun, 9 Jan 2005 11:22:33 -0500

>=20
> Hi folks.  Just setting up a new machine with Python 2.4, and wanted to
> check something.  Under "Installing on Windows", the Matplotlib pages at
> sf.net say:
>=20
>      For standard python installations, you will also need to install
>      either Numeric or numarray in addition to the matplotlib installer.
>      matplotlib provides installers for Numeric and numarray users. It is
>      important that you pick the matplotlib installer that corresponds to
>      your array package.  Ie, if you mostly work with numarray arrays, use
>      the matplotlib numarray installer. matplotlib has a numerix setting =
in
>      the matplotlib rc file (which by default resides in
>      c:\python23\share\matplotlitb\.matplotlibrc) and you should make sure
>      this setting corresponds to your preferred array package.
>=20
> However, the download page:
>=20
>=20=20=20=20=20=20
> http://sourceforge.net/project/showfiles.php?group_id=3D80706&package_id=
=3D82474
>=20
> only differentiates installers by Python version; there's no hint which
> one is for Numpy, numarray, etc.  The one I grabbed
> (matplotlib-0.70.1-win32.py2.4.exe) installed, but complains about not
> being able to find numarray (which is installed, for Python 2.4).  I'd be
> happy to use Numpy, but the only releases available are for Python 2.3.
>=20
> Any suggestions?
>=20
> Thanks,
> Greg Wilson
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

Re: [Matplotlib-users] matplotlib / Python 2.4 / Numarray

[John H. <jdh...@ac...>]

>>>>> "Todd" == Todd Miller <jm...@st...> writes:

    Todd> I verified that matplotlib-0.70 works w/ numarray-1.1.1 on
    Todd> Windows XP using a quick "plot([1,2,3,4]); show();" test.  I
    Todd> noted that TkAgg is now raising an exception when the plot
    Todd> window is closed, but the plot looked fine to me.

Thanks Todd -- fixed in CVS.  This resulted from generating a location
event before the mouse was over the figures, and hence event.x and
event.y were None and downstream in the code this condition was
accounted for.

JDH

Re: [Matplotlib-users] matplotlib / Python 2.4 / Numarray

[Todd M. <jm...@st...>]

I verified that matplotlib-0.70 works w/ numarray-1.1.1 on
Windows XP using a quick "plot([1,2,3,4]); show();" test.  I
noted that TkAgg is now raising an exception when the plot
window is closed,  but the plot looked fine to me.

Cheers,
Todd

Exception in Tkinter callback
Traceback (most recent call last):
  File "h:\python24\lib\lib-tk\Tkinter.py", line 1345, in __call__
    return self.func(*args)
  File
"H:\python24\lib\site-packages\matplotlib\backends\backend_tkagg.py",
lin
e 215, in key_release
    FigureCanvasBase.key_release_event(self, key)
  File
"H:\python24\lib\site-packages\matplotlib\backend_bases.py",
line 677, in
 key_release_event
    event = KeyEvent('key_release_event', self, key,
self._lastx, self._lasty)
  File
"H:\python24\lib\site-packages\matplotlib\backend_bases.py",
line 640, in
 __init__
    LocationEvent.__init__(self, name, canvas, x, y)
  File
"H:\python24\lib\site-packages\matplotlib\backend_bases.py",
line 566, in
 __init__
    if a.in_axes(self.x, self.y):
  File "H:\python24\lib\site-packages\matplotlib\axes.py",
line 1544, in in_axes

    return self.bbox.contains(xwin, ywin)
TypeError: float() argument must be a string or a number