matplotlib

I'm getting a traceback when trying to run tex_demo.py under Windows 
(both Win98 and Win2k).
I *think* I've met the specified requirements.
Any help would be appreciated,
thanks,
Gary R.

Here's a dump with debug-annoying set:


loaded rc file C:\PYTHON23\share\matplotlib\.matplotlibrc
matplotlib version 0.82
verbose.level debug-annoying
interactive is False
platform is win32
loaded modules: ['__future__', 'copy_reg', 'sre_compile', 'distutils', 
'locale', '_sre', '__main__', 'site', '__builtin__', 'datetime', 
'encodings', 'os.path', 'encodings.encodings', 'sre_constants', 
'distutils.string', 'dateutil', 'matplotlib.datetime', 'strop', 
'matplotlib.warnings', 'encodings.codecs', 'matplotlib.sys', 're', 
'ntpath', 'pytz.sys', 'UserDict', 'distutils.sysconfig', 
'encodings.exceptions', 'nt', 'pytz.sets', 'stat', 'zipimport', 
'string', 'warnings', 'encodings.types', '_codecs', 'distutils.os', 
'matplotlib', 'encodings.cp1252', 'sys', 'pytz.tzinfo', 'pytz', 
'pytz.datetime', 'matplotlib.__future__', 'codecs', 'distutils.re', 
'matplotlib.pytz', 'types', 'matplotlib.dateutil', '_locale', 
'matplotlib.os', 'sre', 'bisect', 'matplotlib.distutils', 'signal', 
'distutils.errors', 'linecache', 'itertools', 'sets', 'exceptions', 
'sre_parse', 'pytz.bisect', 'distutils.sys', 'os']
numerix Numeric 23.7
font search path ['C:\\PYTHON23\\share\\matplotlib']
trying fontname C:\PYTHON23\share\matplotlib\cmex10.ttf
trying fontname C:\PYTHON23\share\matplotlib\cmmi10.ttf
trying fontname C:\PYTHON23\share\matplotlib\cmr10.ttf
trying fontname C:\PYTHON23\share\matplotlib\VeraMono.ttf
trying fontname C:\PYTHON23\share\matplotlib\cmsy10.ttf
trying fontname C:\PYTHON23\share\matplotlib\VeraMoBI.ttf
trying fontname C:\PYTHON23\share\matplotlib\cmtt10.ttf
trying fontname C:\PYTHON23\share\matplotlib\Vera.ttf
matplotlib data path C:\PYTHON23\share\matplotlib
loaded ttfcache file C:\PYTHON23\share\matplotlib\.ttffont.cache
backend TkAgg version 8.4
FigureCanvasAgg.draw
RendererAgg.__init__
This is e-TeX, Version 3.141592-2.2 (MiKTeX 2.4)
entering extended mode
! Undefined control sequence.
<*> 'C:\PYTHON
 
23\share\matplotlib\.tex.cache\30565a8911a6bb487e3745c0ea3c822...

! Undefined control sequence.
<*> 'C:\PYTHON23\share
 
\matplotlib\.tex.cache\30565a8911a6bb487e3745c0ea3c822...

! Undefined control sequence.
<*> 'C:\PYTHON23\share\matplotlib
 
\.tex.cache\30565a8911a6bb487e3745c0ea3c822...

! I can't find file `'C:23.tex'.
<to be read again>
                    \global
<*> 'C:\PYTHON23\share\matplotlib\.
 
tex.cache\30565a8911a6bb487e3745c0ea3c822...
Please type another input file name
! Emergency stop.
<to be read again>
                    \global
<*> 'C:\PYTHON23\share\matplotlib\.
 
tex.cache\30565a8911a6bb487e3745c0ea3c822...

No pages of output.
Transcript written on texput.log.

Exception in Tkinter callback
Traceback (most recent call last):
   File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1345, in __call__
     return self.func(*args)
   File 
"C:\PYTHON23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 148, in resize
     self.show()
   File 
"C:\PYTHON23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 151, in draw
     FigureCanvasAgg.draw(self)
   File 
"C:\PYTHON23\Lib\site-packages\matplotlib\backends\backend_agg.py", line 
369, in draw
     self.figure.draw(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\figure.py", line 498, 
in draw
     for a in self.axes: a.draw(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\axes.py", line 1361, 
in draw
     self.xaxis.draw(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\axis.py", line 544, in 
draw
     tick.draw(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\axis.py", line 147, in 
draw
     if self.label1On: self.label1.draw(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\text.py", line 847, in 
draw
     self._mytext.draw(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\text.py", line 334, in 
draw
     bbox, info = self._get_layout(renderer)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\text.py", line 179, in 
_get_layout
     w,h = renderer.get_text_width_height(
   File 
"C:\PYTHON23\Lib\site-packages\matplotlib\backends\backend_agg.py", line 
237, in get_text_width_height
     Z = self.texmanager.get_rgba(s, size, dpi, rgb)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\texmanager.py", line 
276, in get_rgba
     pngfile = self.make_png(tex, dpi, force=False)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\texmanager.py", line 
113, in make_png
     dvifile = self.make_dvi(tex)
   File "C:\PYTHON23\Lib\site-packages\matplotlib\texmanager.py", line 
105, in make_dvi
     shutil.move(dvitmp, dvifile)
   File "C:\PYTHON23\lib\shutil.py", line 170, in move
     copy2(src,dst)
   File "C:\PYTHON23\lib\shutil.py", line 82, in copy2
     copyfile(src, dst)
   File "C:\PYTHON23\lib\shutil.py", line 37, in copyfile
     fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: 
'30565a8911a6bb487e3745c0ea3c8224.dvi'

Oops - sorry about the subject line :-(
Gary

James Boyle writes:

[snip]

 > For values outside the range of the max and min of the normalization, I 
 > have added filled triangles above and below the color bar.
 > This type of display is found in other visualization software. It 
 > allows the scale to just consider values of interest, while providing 
 > information as to the location and relative values of outliers.

I'd also find this very useful.  For comparison, there is something
similar (colorscale) on the matlab central file exchange:

http://tinyurl.com/8yzbe

but it looks like it was broken in the change from R13 to R14.  Not
that I can be of any use adding this, but colorscale also has a nice
feature that:

"The colormap may contain special values for null data areas, and
these special values may be excluded from the scale bar. Or, the
colormap may be deliberately partitioned and shared with a different
image in the same figure, and that image may have its own, entirely
distinct, color scale."

There's a nice walkthrough  here:

http://www.mathworks.com/company/newsletters/digest/nov02/earth.html

Regards, Phil

>>>>> "James" == James Boyle <boyle5@...> writes:

    James> I have also modified the colorbar code( in figure.py) to
    James> scale the width of the colorbar. I generate plots with
    James> aspect ratios of x axis long with respect to the y axis and
    James> in this situation the colorbar gets to be too fat.

The current implementation supports providing a custom axes for the
colorbar axes.  Do you think it would be useful in addition to support
something like a fracw (fraction width) keyword arg for the default
width of the colorbar when making an automatic colorbar axes.  If so
we should support this for vertical colorbars as well.  Something like
fracax=0.1, the fraction of the axis (x for horizontal or y for
vertical colorbars) taken up by the colorbar when automatically
resizing the image axes.

    James> The purpose of this long winded message is to advocate that
    James> the color bar code be modified to make this facility an
    James> option( ie specified color map, normalization, width
    James> scaling and end caps).

    James> I am willing to do this myself - but I would need some
    James> help. Previously, John suggested that I make the routine
    James> that does the fill calls derive from ScalarMappable. This
    James> would make the colorbar color map and scaling come along
    James> naturally. My skill level is such that I have not been able
    James> to get this to work - I am willing but not very able. My
    James> thought now is to make some substantial additions to
    James> colorbar.

All of this sounds fine to me -- let me know how I can help.

JDH

On Thursday 30 June 2005 11:15 am, Jeff Peery wrote:
> Hello,
>
> I wrote a small WXAgg program with wxpython. I'm plotting simple
> datasets, right now I'm plotting an array of approx. 450 points. The
> graphing is very slow. What can I do to speed this up? I have python
> 2.4, wxpython 2.4, and this is what I'm using for matplotlib
> 'matplotlib-0.80.win32-py2.4.exe'.

Have you checked the list archives? There has been some discussion about speed 
traps that you can take steps to avoid. For example, are you running a script 
with interactive mode on? That can cause a big performance hit. 

Also, if you provide a brief example script, along with any relevant changes 
you have made to matplotlibrc, and some detail about how long it takes to 
plot (maybe some profiling?), we might be able to provide some more useful 
suggestions.

-- 

Darren

>>>>> "Darren" =3D=3D Darren Dale <dd55@...> writes:


    Darren> Also, if you provide a brief example script, along with
    Darren> any relevant changes you have made to matplotlibrc, and
    Darren> some detail about how long it takes to plot (maybe some
    Darren> profiling?), we might be able to provide some more useful
    Darren> suggestions.

A script is by far the most useful thing you can provide. =20

Note that there was an optimization for line marker drawing on win32
introduced in matplotlib-0.81 From the release notes:

   Fast markers on win32 The marker cache optimization is finally
   available for win32, after an agg bug was found and fixed (thanks
   Maxim!). Line marker plots should be considerably faster now on
   win32. The original optimization announcement is ay
   http://matplotlib.sourceforge.net/whats_new.html#0.72-line_marker_opti=
mizations_in_agg


See also http://matplotlib.sourceforge.net/faq.html#SLOW

JDH



=00

Jeff, 

I agree with John -- matplotlib and the wxAgg backend 
don't seem slow to me.  For simple line drawings in 
'stripchart mode', where a line is being updated as 
fast as possible, I regularly get ~12 plots per second
with wxAgg and mpl 0.81+ on Windows.  It's hard for me 
to consider that slow, but you weren't specific about 
what you were expecting.

Do the examples at 
 http://cars.uchicago.edu/~newville/Python/MPlot 

help? MPlot gives a wxPanel and wxFrame for simple line 
drawings that gives GUI-controlled customization of line 
color and style, etc and provides simple ways for end 
users to zoom in/out, print, and saving of images. The 
examples/test.py includes a stripchart-like plot.

--Matt

>>>>> "James" == James Boyle <boyle5@...> writes:

    James> Say I have drawn a plot and now I want to make an
    James> annotation on the top of the plot outside the axis.  In my
    James> case I want to put a filled triangle up there in a certain
    James> location. I am using a polygon - patch to make the figure.

    James> How does one do this? I have tried turning the clipping off
    James> but to no avail - I can put my triangle anywhere within the
    James> axis but if it is outside it disappears. In the manual
    James> there is an example for placing text outside the axis but
    James> not patches.

The problem you are encountering is that the Axes will automatically
set the clipbox when you call add_patch, so you need to make the call
to turn off clipping *after* adding it to the axes

    from pylab import figure, show
    from matplotlib.patches import RegularPolygon

    fig = figure()
    ax = fig.add_subplot(111)

    # above the yaxis and centered on xaxis; Axes coords
    tri = RegularPolygon((0.5, 1.05), 3, radius=0.2, transform=ax.transAxes)

    # adding the patch to the axes automatically sets the clipbox
    ax.add_patch(tri)

    # so you need to turn it off after adding it
    tri.set_clip_on(False)

    show()

You can also add patches and lines directly to the Figure instance, as
follows, but these are drawn before the Axes and so are behind them

    from pylab import figure, show
    from matplotlib.patches import RegularPolygon

    fig = figure()
    ax = fig.add_axes([0.1,0.1, 0.8, 0.6])

    # Figure coords
    tri = RegularPolygon((0.5, 0.8), 3, radius=0.2,  transform=fig.transFigure)

    fig.patches.append(tri)

    show()

If there is a need to customize this further, let me know.  Eg, we
could move the drawing call for the lines and patches below the Axes
draw so they come out on top.


JDH

Thanks John this works just fine - I consistently set the clipping off 
- BEFORE adding the patch.

--Jim

On Jun 29, 2005, at 1:13 PM, John Hunter wrote:

>>>>>> "James" == James Boyle <boyle5@...> writes:
>
>     James> Say I have drawn a plot and now I want to make an
>     James> annotation on the top of the plot outside the axis.  In my
>     James> case I want to put a filled triangle up there in a certain
>     James> location. I am using a polygon - patch to make the figure.
>
>     James> How does one do this? I have tried turning the clipping off
>     James> but to no avail - I can put my triangle anywhere within the
>     James> axis but if it is outside it disappears. In the manual
>     James> there is an example for placing text outside the axis but
>     James> not patches.
>
> The problem you are encountering is that the Axes will automatically
> set the clipbox when you call add_patch, so you need to make the call
> to turn off clipping *after* adding it to the axes
>
>     from pylab import figure, show
>     from matplotlib.patches import RegularPolygon
>
>     fig = figure()
>     ax = fig.add_subplot(111)
>
>     # above the yaxis and centered on xaxis; Axes coords
>     tri = RegularPolygon((0.5, 1.05), 3, radius=0.2, 
> transform=ax.transAxes)
>
>     # adding the patch to the axes automatically sets the clipbox
>     ax.add_patch(tri)
>
>     # so you need to turn it off after adding it
>     tri.set_clip_on(False)
>
>     show()
>
> You can also add patches and lines directly to the Figure instance, as
> follows, but these are drawn before the Axes and so are behind them
>
>     from pylab import figure, show
>     from matplotlib.patches import RegularPolygon
>
>     fig = figure()
>     ax = fig.add_axes([0.1,0.1, 0.8, 0.6])
>
>     # Figure coords
>     tri = RegularPolygon((0.5, 0.8), 3, radius=0.2,  
> transform=fig.transFigure)
>
>     fig.patches.append(tri)
>
>     show()
>
> If there is a need to customize this further, let me know.  Eg, we
> could move the drawing call for the lines and patches below the Axes
> draw so they come out on top.
>
>
> JDH
>

Hi Werner, 

This should be tested on Mac and Linux too.  I had portability
problems when I originally wrote the printing support.  I can
believe that wx has gotten better.

But also, the current Printer_Setup() provides a simple way to
control the size of the image on the paper. I didn't see that on
yours.

--Matt

On Tue, 28 Jun 2005, Werner F. Bruhin wrote:

> Hi John,
> 
> The attached backend_wx contains "def Printer_Setup2(self, 
> event=None):", which uses the standard wxPython printer setup dialog 
> this works for me on Windows XP Pro SP1, and Windows 2000.
> 
> Any chance that this could go into the next release?
> 
> See you
> Werner
>

Hi Matt,

Matt Newville wrote:

>Hi Werner, 
>
>This should be tested on Mac and Linux too.  I had portability
>problems when I originally wrote the printing support.  I can
>believe that wx has gotten better.
>  
>
Agree, however I don't have access to either of those, like to get a Mac 
but this won't be in the future.

>But also, the current Printer_Setup() provides a simple way to
>control the size of the image on the paper. I didn't see that on
>yours.
>  
>
I did not see Printer_Setup2() as a replacement of Printer_Setup() but 
as an alternative.  It uses the wxPython standard stuff, so I don't know 
if the image size can be done with it, will have another look at this 
sometimes next week.

See you
Werner

>--Matt
>
>On Tue, 28 Jun 2005, Werner F. Bruhin wrote:
>
>  
>
>>Hi John,
>>
>>The attached backend_wx contains "def Printer_Setup2(self, 
>>event=None):", which uses the standard wxPython printer setup dialog 
>>this works for me on Windows XP Pro SP1, and Windows 2000.
>>
>>Any chance that this could go into the next release?
>>
>>See you
>>Werner
>>
>>    
>>
>
>
>
>
>
>  
>

>>>>> "Brent" == Brent Hueth <bhueth@...> writes:

    Brent> This is a problem for me only b/c I'm trying to generate a
    Brent> plot with a total number of subplots > 10.

    Brent> I can't seem to track down the source of the discrepancy.

    Brent> Thanks,

This is a bug in 0.82 that is fixed in CVS and will be fixed in the
next bugfix release.

The patch that fixed it is

http://sourceforge.net/tracker/index.php?func=detail&aid=1222180&group_id=80706&atid=560722

JDH

>>>>> "Jeff" == Jeff Whitaker <jswhit@...> writes:

    Jeff> Michael: By popular demand, I put this back in 0.5.1.  You
    Jeff> can now pass an axes instance to any Basemap method.  The
    Jeff> default is 'ax=None', in which case pylab.gca is used to get
    Jeff> the current one.  Does this solve your problem?

You can potentially get into trouble by simply importing the pylab
module at all since pylab will try and import the default backend.
This usually isn't fatal, but isn't ideal either.  I would suggest
conditionally importing pylab only if it is needed, eg when ax=None.

The use case you would be avoiding is for example when the user hasn't
changed the default backend (GTKAgg) from .matplotlibrc.  They may be
using non-pylab basemap in pure agg mode over a web app server.  When
you import pylab, the module will try and import pygtk, which will
fail if pygtk is not installed or if there is no X11 connection.  Of
course, the user could change the default backend in the rc file, but
one point of the OO interface is to have as little magic as possible.
By conditionally importing pylab, you can avoid these kinds of
problems.

JDH

Jeff Whitaker wrote:
> Chris Barker wrote:
> It makes sense to me to have a given Basemap[ object 
>> associated with one and only one axes, but maybe I'm weird. 
> 
> No you're not weird.  But I've been told that some people building GUI 
> apps want to use the same Basemap instance to draw in different windows.

Fair enough. OO is not always the best way to go.

>> I did use it at first, but decided that a simple pyrex wrapper was 
>> simpler and easier to maintain.

You're probably right about that. I still haven't used pyrex, but it 
looks like a great idea. Maybe I have a reason to now.

>> My module is not really fully optimized to take advantage of numarray 
>> - it does the transformation one point at a time in a c-loop and 
>> stuffs the result in a list.  So, there's a lot of overhead in 
>> repeatedly calling the proj4 c-routine.

Darn, that's exactly the kind of thing I'm hoping to avoid,.

>> It would be a lot faster to 
>> recode the proj4 c-routine to process the whole array at once.

I hope I'll get a chance to do this, but I'll probably start by using it 
like it is, and see how the performance is. If do work on it, I'm going 
to try to use the new "array interface" in the latest Numeric (at least 
I think it's there, the Numeric list has been quite lately).

> Chris:  I should say that the reason I haven't done this is related to 
> the reason I decided to not use the Thuban module - I know very little 
> about C programming and didn't want to mess with C code.

I can understand that. I'm pretty weak in C myself. Every time I use it, 
I find it painful, and run back to Python as soon as I can.

I hope you won't mind helping me out a bit with PROJ4, I'm still having 
a hard time wrapping my brain around projections.

-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

Chris.Barker@...

John Hunter wrote:

>>>>>>"Jeff" == Jeff Whitaker <jswhit@...> writes:
>>>>>>            
>>>>>>
>
>    Jeff> Michael: By popular demand, I put this back in 0.5.1.  You
>    Jeff> can now pass an axes instance to any Basemap method.  The
>    Jeff> default is 'ax=None', in which case pylab.gca is used to get
>    Jeff> the current one.  Does this solve your problem?
>
>You can potentially get into trouble by simply importing the pylab
>module at all since pylab will try and import the default backend.
>This usually isn't fatal, but isn't ideal either.  I would suggest
>conditionally importing pylab only if it is needed, eg when ax=None.
>
>The use case you would be avoiding is for example when the user hasn't
>changed the default backend (GTKAgg) from .matplotlibrc.  They may be
>using non-pylab basemap in pure agg mode over a web app server.  When
>you import pylab, the module will try and import pygtk, which will
>fail if pygtk is not installed or if there is no X11 connection.  Of
>course, the user could change the default backend in the rc file, but
>one point of the OO interface is to have as little magic as possible.
>By conditionally importing pylab, you can avoid these kinds of
>problems.
>
>JDH   
>  
>
John:  OK, I've fixed it so pylab is not imported at all if either (1) 
the 'ax' keyword is used in Basemap.__init__ (in which case only one 
axes instance is used by that Basemap instance), or (2) the 'ax' keyword 
is used in all Basemap method calls that do drawing (in which case 
different axes may be used by the same Basemap instance).  If you don't 
use the 'ax' keyword, basemap methods behave like their pylab 
counterparts (i.e. pylab.gca is used to get the current axis).

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Jeff Whitaker wrote:
> John:  OK, I've fixed it so pylab is not imported at all if either (1) 
> the 'ax' keyword is used in Basemap.__init__ (in which case only one 
> axes instance is used by that Basemap instance), or (2) the 'ax' keyword 
> is used in all Basemap method calls that do drawing (in which case 
> different axes may be used by the same Basemap instance).  If you don't 
> use the 'ax' keyword, basemap methods behave like their pylab 
> counterparts (i.e. pylab.gca is used to get the current axis).

Nice job Jeff. You've come up with a solution that satisfies a wide 
variety of uses. Hurray for keyword arguments!

-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

Chris.Barker@...

On Tue, 28 Jun 2005, Jeff Whitaker wrote:

> John:  OK, I've fixed it so pylab is not imported at all if either (1) the 
> 'ax' keyword is used in Basemap.__init__ (in which case only one axes 
> instance is used by that Basemap instance), or (2) the 'ax' keyword is used 
> in all Basemap method calls that do drawing (in which case different axes may 
> be used by the same Basemap instance).  If you don't use the 'ax' keyword, 
> basemap methods behave like their pylab counterparts (i.e. pylab.gca is used 
> to get the current axis).

Great!  That's perfect for us.  Thanks for the quick response.

We have exactly the setup that John was describing.  We use Basemap in 
cron jobs that don't have any X windows support.  Our default backend is 
Qt, and Qt itself aborts and core dumps (!) if you try to use it when 
there's no X server present.  So we wanted to avoid pylab loading a 
backend.

I guess we'll see these changes in the next release, 0.5.2 or 0.6, 
whichever is next, yes?

Thanks again,

Michael

========================================================================
  Michael Brady
  Jet Propulsion Laboratory (M/S 301-140L)
  4800 Oak Grove Drive
  Pasadena, CA  91109                 E-mail: Michael.Brady@... 
========================================================================