matplotlib-users Mailing List for matplotlib

Robert Kern wrote:

> Exuberant ctags
>
> http://ctags.sourceforge.net/
>
Which, as it turns out, is the version of ctags on Fedora Core 3.  I did 
a 'ctags -R' in the matplotlib root directory and am now happily 
browsing the source using nedit.

Thanks, Robert!

Steve

Stephen Walton wrote:

> I'm sure the code is fine, John, and it's just me.  Specifically, if I 
> want to see how matplotlib is doing something, I can't just trace 
> function calls like I'm used to doing with Fortran and C, because there 
> are methods too and I have to find the class which defines those methods 
> to see what's happening.  Is there anything like ctags for Python?

Exuberant ctags

http://ctags.sourceforge.net/

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

John Hunter wrote:

>>>>>>"Stephen" == Stephen Walton <ste...@cs...> writes:
>>>>>>            
>>>>>>
>Does changing the rc param
>
>  image.origin : upper             # lower | upper
>
>to lower help?
>  
>
Yes, it makes the image the right way around.  I was simply confused 
because I expected the pixel at (x,y) in the imshow display to be the 
value of img[x,y].  It appears not to be.  I hasten to add MATLAB's 
worse, as the pixel at (x,y) is actually the value of img[y,x];  MATLAB 
displays with the first array coordinate increasing downward and the 
second from left to right.

>    Stephen> I've tried to look at the source, really, but I feel like
>    Stephen> I'm *years* away from being enough of a Python hacker to
>    Stephen> understand matplotlib.
>
>Hmm, the code's not that bad is it :-)
>  
>
I'm sure the code is fine, John, and it's just me.  Specifically, if I 
want to see how matplotlib is doing something, I can't just trace 
function calls like I'm used to doing with Fortran and C, because there 
are methods too and I have to find the class which defines those methods 
to see what's happening.  Is there anything like ctags for Python?

Steve

Some ability to specify empty space between subplots would be very 
convenient.  I'm not sure if this could best be done at figure creation or 
at subplot creation with an additional argument that says how much space 
to leave above or below.

The motivation is that creating subplots with separate titles is a very
common desire, and doing so now results in title text that invariably
overlaps the plot above (or if the font is reduced enough, it may fit but
looks squished in there).

Using manual axes creation is another approach that has been suggested, 
but this is a pain and seems to obviate the convenience of subplot().

If there is a better approach than creating custom axes, I'd love to hear
about it.

Thanks to all the pylab developers!

Rich

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:

    Stephen> Hi, I was just comparing images displayed with imshow()
    Stephen> with what I get from IRAF's display command and ds9.  The
    Stephen> latter puts the first axis increasing horizontally and
    Stephen> the second axis increasing vertically, as if the image
    Stephen> array were addressed as img[ix,iy], where ix and iy are
    Stephen> integer x and y coordinates.  The axes imshow() produces
    Stephen> are labeled as if this is true for it as well, but in
    Stephen> fact the image is upside down with respect to what I see
    Stephen> with IRAF.  Even odder, to see the same display I see in
    Stephen> IRAF I have to do imshow(img[::-1,:]), as if I'm
    Stephen> reversing the direction of the first axis.


Does changing the rc param

  image.origin : upper             # lower | upper

to lower help?


    Stephen> I've tried to look at the source, really, but I feel like
    Stephen> I'm *years* away from being enough of a Python hacker to
    Stephen> understand matplotlib.

Hmm, the code's not that bad is it :-)

JDH

check out the .matplotlibrc image.origin configuration parameter. The 
default is to have pixel 0,0 on the upper left which is opposite of 
what us weird astronomers think is the natural locationl

Perry

On Apr 7, 2005, at 2:08 PM, Stephen Walton wrote:

> Hi,
>
> I was just comparing images displayed with imshow() with what I get 
> from IRAF's display command and ds9.  The latter puts the first axis 
> increasing horizontally and the second axis increasing vertically, as 
> if the image array were addressed as img[ix,iy], where ix and iy are 
> integer x and y coordinates.  The axes imshow() produces are labeled 
> as if this is true for it as well, but in fact the image is upside 
> down with respect to what I see with IRAF.  Even odder, to see the 
> same display I see in IRAF I have to do imshow(img[::-1,:]), as if I'm 
> reversing the direction of the first axis.
>
> I've tried to look at the source, really, but I feel like I'm *years* 
> away from being enough of a Python hacker to understand matplotlib.
>
> Steve
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I was just comparing images displayed with imshow() with what I get from 
IRAF's display command and ds9.  The latter puts the first axis 
increasing horizontally and the second axis increasing vertically, as if 
the image array were addressed as img[ix,iy], where ix and iy are 
integer x and y coordinates.  The axes imshow() produces are labeled as 
if this is true for it as well, but in fact the image is upside down 
with respect to what I see with IRAF.  Even odder, to see the same 
display I see in IRAF I have to do imshow(img[::-1,:]), as if I'm 
reversing the direction of the first axis.

I've tried to look at the source, really, but I feel like I'm *years* 
away from being enough of a Python hacker to understand matplotlib.

Steve

Hi,

I have some problems compiling an .exe-file for my application. I use
wxPython together with matplotlib and tried to make an .exe-file with both
packages for the first time.

Windows XP
Python 2.4
wxPython 2.5.3.1
matplotlib 0.74

I checked the FAQ at the matplotlib homepage and the py2exe-examples and
did the following:



from distutils.core import setup
import glob
import py2exe

data = glob.glob(r'C:\Python24\Lib\site-packages\matplotlib\*')
data.append(r'C:\Python24\Lib\site-packages\matplotlib\.matplotlibrc')

setup(
    console = ["PanelCheck.py"],
    data_files = [("matplotlibdata", data)],
    )


After py2exe is finished I find both folders 'dist' and 'build' as ususal,
however I can't finde an .exe-file of my application PanelCheck.py in the
dist-folder.
I assume that 'window' is what I want to use in the code above, but when I
do that I get the following error:

--(just a small part of the console output)--
error: can't copy 'C:\Python24\Lib\site-packages\matplotlib\backends':
doesn't exist or not a regular file


What am I doing wrong? Help is really appreciated!

Oliver

Hello NG,

    this morning I have done the really BIG mistake of uninstalling the
following things:

- Numeric 23.5
- ctypes 0.9.2
- numarray 1.1.1
- Matplotlib 0.72

And I have installed the following:

- Numeric 23.8
- ctypes 0.9.6
- numarray 1.2.3
- Matplotlib 0.74

Using py2exe 0.5.4, now I get some errors on not-found modules, that I pu=
t
at the end of the mail. I have never encountered these problems with olde=
r
versions of the aforementioned tools. Please note that, a part the VTK th=
ings,
almost all the missing modules are from numerix/backends. If I try to sta=
rt
the application, I get a Visual C++ runtime error (and not the usual MYEX=
E.exe.log
message from py2exe, so I do not know how to track the error). 
I am on a Windows 2000 machine.
Deinstalling the new tools and re-installing the old ones didn't help any=
more...

Does anyone have a suggestion?

['backends.draw_if_interactive', 'backends.new_figure_manager', 'backends=
.show',
 'cephes', 'dl', 'libvtkCommonPython', 'libvtkFilteringPython', 'libvtkGr=
aphicsP
ython', 'libvtkHybridPython', 'libvtkIOPython', 'libvtkImagingPython', 'l=
ibvtkPa
rallelPython', 'libvtkPatentedPython', 'libvtkRenderingPython', 'numerix.=
ArrayTy
pe', 'numerix.Complex', 'numerix.Complex32', 'numerix.Complex64', 'numeri=
x.Float
', 'numerix.Float32', 'numerix.Float64', 'numerix.Int', 'numerix.Int16',
'numeri
x.Int32', 'numerix.Int8', 'numerix.Matrix', 'numerix.UInt16', 'numerix.UI=
nt32',
'numerix.UInt8', 'numerix.absolute', 'numerix.add', 'numerix.allclose',
'numerix
.alltrue', 'numerix.arange', 'numerix.arccos', 'numerix.arccosh', 'numeri=
x.arcsi
n', 'numerix.arcsinh', 'numerix.arctan', 'numerix.arctan2', 'numerix.arct=
anh',
'
numerix.argmax', 'numerix.argmin', 'numerix.argsort', 'numerix.around',
'numerix
.array', 'numerix.arrayrange', 'numerix.asarray', 'numerix.asum', 'numeri=
x.bitwi
se_and', 'numerix.bitwise_or', 'numerix.bitwise_xor', 'numerix.ceil', 'nu=
merix.c
hoose', 'numerix.clip', 'numerix.compress', 'numerix.concatenate', 'numer=
ix.conj
ugate', 'numerix.convolve', 'numerix.cos', 'numerix.cosh', 'numerix.cross=
_correl
ate', 'numerix.cumproduct', 'numerix.cumsum', 'numerix.diagonal', 'numeri=
x.divid
e', 'numerix.dot', 'numerix.equal', 'numerix.exp', 'numerix.fabs', 'numer=
ix.fft.
fft', 'numerix.floor', 'numerix.fmod', 'numerix.fromfunction', 'numerix.f=
romstri
ng', 'numerix.greater', 'numerix.greater_equal', 'numerix.hypot', 'numeri=
x.ident
ity', 'numerix.indices', 'numerix.innerproduct', 'numerix.less', 'numerix=
.less_e
qual', 'numerix.log', 'numerix.log10', 'numerix.logical_and', 'numerix.lo=
gical_n
ot', 'numerix.logical_or', 'numerix.logical_xor', 'numerix.matrixmultiply=
',
'num
erix.maximum', 'numerix.minimum', 'numerix.mlab.amax', 'numerix.mlab.amin=
',
'num
erix.mlab.cov', 'numerix.mlab.diff', 'numerix.mlab.flipud', 'numerix.mlab=
.hannin
g', 'numerix.mlab.rand', 'numerix.mlab.std', 'numerix.mlab.svd', 'numerix=
.multip
ly', 'numerix.negative', 'numerix.nonzero', 'numerix.not_equal', 'numerix=
.nx',
'
numerix.ones', 'numerix.outerproduct', 'numerix.pi', 'numerix.power', 'nu=
merix.p
roduct', 'numerix.put', 'numerix.putmask', 'numerix.rank', 'numerix.ravel=
',
'num
erix.repeat', 'numerix.reshape', 'numerix.resize', 'numerix.searchsorted'=
,
'nume
rix.shape', 'numerix.sin', 'numerix.sinh', 'numerix.size', 'numerix.somet=
rue',
'
numerix.sort', 'numerix.sqrt', 'numerix.subtract', 'numerix.swapaxes', 'n=
umerix.
take', 'numerix.tan', 'numerix.tanh', 'numerix.trace', 'numerix.transpose=
',
'num
erix.where', 'numerix.which', 'numerix.zeros', 'vtkParallelPython', 'matp=
lotlib.
numerix.absolute', 'matplotlib.numerix.equal', 'numarray.Complex', 'numar=
ray.Com
plex32', 'numarray.Complex64', 'numarray.Float', 'numarray.Float32', 'num=
array.F
loat64', 'numarray.Int', 'numarray.Int16', 'numarray.Int32', 'numarray.In=
t8',
'n
umarray.NumArray', 'numarray.UInt16', 'numarray.UInt32', 'numarray.UInt8'=
,
'numa
rray._dotblas', 'numarray.asarray', 'numarray.dot', 'numarray.fromlist',
'numarr
ay.shape', 'numarray.typecode', 'numarray.zeros', 'wx.BitmapFromImage',
'wx.Empt
yIcon']

>>>>> "jim" == jim  <jl...@yv...> writes:

    jim> John: What I need to do is create drawings of windows (as in
    jim> plug holes in houses and let in light) with grid and other
    jim> options on the fly.

    jim> So what I need are the graphic primitives -- canvas, lines,
    jim> fills ...  The output needs to be a graphic file.

You probably want to be using matplotlib primitives.  Assuming you
have a matplotlib.axes.Axes (or Subplot) instance stored as "ax", The
primitives are

  matplotlib.lines.Line2D           - add with ax.add_line 
  matplotlib.patches.Rectangle      - add with ax.add_patch
  matplotlib.patches.Polygon        - add with ax.add_patch
  matplotlib.patches.RegularPolygon - add with ax.add_patch
  matplotlib.patches.Circle         - add with ax.add_patch
  matplotlib.patches.Text           - add with ax.add_artist

Ie, there are not too many mpl primitives, and using these will
insulate you from changes in the mpl backend (renderer) api.  The
backend API is meant only for mpl developers.  The classes referred to
above are all part of the matplotlib Artist hierarchy.

    jim> I will go back and study the docs, but a suggestion of what
    jim> area to use would be most welcome.  Or, of course, a
    jim> different module than matplotlib if that would be more
    jim> appropriate.

To reiterate, there is one base class matplotlib.artist.Artist that
all the objects that render into the figure derive from.  From this,
there are just a few derived classes to be aware of: Line2D, Patch,
Text, and Collection.  From these there are a few more derived classes (eg
Patch and Collection have some specialized derived classes, Line2D and
Text do not as of yet).  Other Artists (including Figure, Axes,
Legend, Table and so on) are simply composites of these primitive
types.  See the following class docs for more info:

  http://matplotlib.sourceforge.net/matplotlib.artist.html
  http://matplotlib.sourceforge.net/matplotlib.lines.html
  http://matplotlib.sourceforge.net/matplotlib.patches.html
  http://matplotlib.sourceforge.net/matplotlib.text.html
  http://matplotlib.sourceforge.net/matplotlib.collections.html

In short, you should concentrate on building the primitive types you
need rather than calling the renderer methods directly.  The
primitives will call the right renderer methods as necessary (as they
do in matplotlib.lines, for example).

Hope this helps,
JDH

John:

What I need to do is create drawings of windows (as in plug holes in houses 
and let in light) with grid and other options on the fly.

So what I need are the graphic primitives -- canvas, lines, fills ...
The output needs to be a graphic file.  

I will go back and study the docs, but a suggestion of what area to use would 
be most welcome.  Or, of course, a different module than matplotlib if that 
would be more appropriate.

Thanks,
Jim

On Wednesday 06 April 2005 08:13 pm, you wrote:
> >>>>> "jim" == jim  <jl...@yv...> writes:
> 
>     jim> Running this script gives the results below #! /usr/bin/env
>     jim> python
> 
>     jim> from matplotlib.backends.backend_agg import RendererAgg from
>     jim> matplotlib.transforms import Value
> 
> I know there are examples in the pdf user's guide discussing how to
> use the backend renderer directly, and these are meant mostly to be
> helpful to matplotlib developers.  Unfortunately, the guide has lagged
> behind the current development state.  The backend renderer API is in
> a transition state right now as we try to introduce some new methods
> to solve some old problems.  In particular, the draw_lines method that
> you are experiencing problems with has recently had a change in its
> call signature.
> 
> These changes have been discussed at some length recently on the
> matplotlib-devel list.  If you are interested, you might want to
> browse the matplotlib-devel archives and/or join the mailing list; see
> for example
> 
http://sourceforge.net/mailarchive/forum.php?thread_id=6938045&forum_id=36187 .
> 
> Thanks for reporting this discrepancy -- in the near term the backend
> API shouldn't be used on the user side.  If there is something you
> want to do but can't in the current API let me know.
> 
> As for the platform specific differences you report, my first guess is
> that the matplotlib versions may not be the same.  I wouldn't expect
> platform specific differences in the backend API for the same version.
> 
> JDH
> 
> 
> 
> 

>>>>> "jim" == jim  <jl...@yv...> writes:

    jim> Running this script gives the results below #! /usr/bin/env
    jim> python

    jim> from matplotlib.backends.backend_agg import RendererAgg from
    jim> matplotlib.transforms import Value

I know there are examples in the pdf user's guide discussing how to
use the backend renderer directly, and these are meant mostly to be
helpful to matplotlib developers.  Unfortunately, the guide has lagged
behind the current development state.  The backend renderer API is in
a transition state right now as we try to introduce some new methods
to solve some old problems.  In particular, the draw_lines method that
you are experiencing problems with has recently had a change in its
call signature.

These changes have been discussed at some length recently on the
matplotlib-devel list.  If you are interested, you might want to
browse the matplotlib-devel archives and/or join the mailing list; see
for example
http://sourceforge.net/mailarchive/forum.php?thread_id=6938045&forum_id=36187 .

Thanks for reporting this discrepancy -- in the near term the backend
API shouldn't be used on the user side.  If there is something you
want to do but can't in the current API let me know.

As for the platform specific differences you report, my first guess is
that the matplotlib versions may not be the same.  I wouldn't expect
platform specific differences in the backend API for the same version.

JDH

Running this script gives the results below

#! /usr/bin/env python

from matplotlib.backends.backend_agg import RendererAgg
from matplotlib.transforms import Value

dpi   = Value(100.0)

o = RendererAgg(100,200, dpi)
gc = o.new_gc()
gc.set_foreground('k')
face = (1,1,1)
   
gc.set_linewidth(1)
o.draw_rectangle(gc, face, 0,0, 100,200)

o.draw_lines(gc, (1,100,1), (1,100,200))

o._renderer.write_png("test.png")

#*** Results from running the above ****************
# J:\>python test4.py
# Traceback (most recent call last):
#   File "test4.py", line 16, in ?
#     o.draw_lines(gc, x, y)
# IndexError: Unexpected SeqBase<T> length.
#
# J:\>
#****************************************************

Running in on linux-gentoo 2004 runs just fine.  Gives the expected output 
file.

My windows setup is win2k, python2.4
I loaded numeric and numarray.  Gives the same results in either case.

I have Borland5.5 installed have build an extension with it.  Other than that 
have several other nonstock modules installed.

Running it on win98 with python 2.4 gives a different error, but much the same 
effect.

Thanks in advance
Jim Hurlburt
Yakima, WA