matplotlib-users Mailing List for matplotlib (Page 8)

Hello John,


>
>There is nothing wrong with instantiating Text instances yourself and
>adding them to the figure or axes manually as you did, but both the
>Axes and Figure have helper methods "text" which define a default
>transformation that can be overridden
>
>So
>
>  t = Text(x=x, y=y, text=text) 
>  t.set_transform(axes.transAxes)
>  ax.texts.append(t)
>
>is equivalent to 
>
>  ax.text(x, y, text, transform=ax.transAxes) 
>
>  
>
ax.text was my starting point to understand the usage of Text(). For my 
application I need a very detailed control of the objects I create, this 
is why I prefer the manual approach.

>
>If you have time and inclination to write a transformations tutorial
>for the wiki, that would be great.
>
>  
>
Not tonight, but I will!


Thanks so much for your answer,

Niklas.

My fault, I didn't read with enougth attention the help. I have another 
question so:

For a same matrice with imshow and matshow. I obtain the two images include.
They are very  different for the axes and the aspect.

I try to use origin and preserve with imsho to have something similar to 
matshow but the result are not better and for the preserve command it's 
worst.
I must admit I don't understand very well how this two commands work, 
especially for the origin where the pixels are count.

N.

Fernando Perez wrote:

> Humufr wrote:
>
>>     Hello,
>>
>> I think that there are a problem with matshow in the current 
>> matplotlib cvs version:
>>
>> m1 = zeros((12,12))
>> matshow(m1,origin='upper')
>> matshow(m1,origin='lower')
>>
>> give me exactly the same result. The lower case is not working.
>
>
> It's not a bug, it's a feature :)
>
> In [19]: matshow?
> Type:           function
> Base Class:     <type 'function'>
> String Form:    <function matshow at 0x411f1064>
> Namespace:      Interactive
> File:           /usr/lib/python2.3/site-packages/matplotlib/pylab.py
> Definition:     matshow(*args, **kw)
> Docstring:
>     Display an array as a matrix in a new figure window.
>
>     The origin is set at the upper left hand corner and rows (first 
> dimension
>     of the array) are displayed horizontally.  The aspect ratio of the 
> figure
>     window is that of the array, as long as it is possible to fit it 
> within
>     your screen with no stretching.  If the window dimensions can't 
> accomodate
>     this (extremely tall/wide arrays), some stretching will inevitably 
> occur.
>
>     Tick labels for the xaxis are placed on top by default.
>
>
> Basically matshow hardcodes origin='lower', as the code shows:
>
>     # imshow call: use 'lower' origin (we'll flip axes later)
>     kw['origin'] = 'lower'
>
> I thought the docstring was clear enough, by saying:
>
>     The origin is set at the upper left hand corner and rows (first 
> dimension
>     of the array) are displayed horizontally.
>
> but if you feel a more emphatic description is needed, let us know.
>
> The intent of matshow is precisely to serve as an imshow wrapper with 
> fixed origin at the top left for matrix-type displays.  It uses imshow 
> under the hood, so it doesn't take  any fine control away from you, 
> rather it is a specialized function for displaying arrays which are 
> meant to be understood as matrices in the traditional linear algebra 
> sense.
>
> OTOH, if further functionality for it is desired, I'm sure patches 
> would be welcome.  It serves my needs fairly well, but I'm sure it can 
> always be improved.
>
> Cheers,
>
> f
>

I'm trying to get the latest matplotlib to build on Solaris 8 (gcc 3.3.2,
Python 2.3.4) and am having some trouble.  We have stuff installed in
unusual places, so I've had to tweak the build environment a bit:

    export LD_LIBRARY_PATH=/opt/lang/lib:/opt/app/lib:/opt/app/gnome-2.4/lib
    export PKG_CONFIG_PATH=/opt/app/gnome-2.4/lib/pkgconfig
    python setup.py build

Starting from scratch everything seems to build fine until it tries to
compile gtkagg.  After a build attempt from scratch (which fails, but emits
lots of distutils copying messages and other successful gcc commands), a
second try yields:

    running build
    running build_py
    running build_ext
    building 'matplotlib.backends._gtkagg' extension
    gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -Isrc -Iswig -Iagg23/include -I. -I/usr/local/include -I/usr/local/include/freetype2 -Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2 -I/usr/local/include/freetype2 -I/usr/local/include -I/opt/app/gnome-2.4//include/pygtk-2.0 -I/opt/app/gnome-2.4//include/glib-2.0 -I/opt/app/gnome-2.4//lib/glib-2.0/include -I/opt/app/gnome-2.4//include/gtk-2.0 -I/opt/app/gnome-2.4//lib/gtk-2.0/include -I/opt/app/gnome-2.4//include -I/usr/openwin/include -I/opt/app/gnome-2.4//include/atk-1.0 -I/opt/app/gnome-2.4//include/pango-1.0 -I/opt/app/freetype-2.1.5/include/freetype2 -I/opt/app/freetype-2.1.5/include -I/opt/app/fontconfig-2.2.0/include -I/opt/app/gnome-2.4//include/glib-2.0 -I/opt/app/gnome-2.4//lib/glib-2.0/include -I/opt/lang/python/include/python2.3 -c src/_gtkagg.cpp -o build/temp.solaris-2.8-i86pc-2.3/src/_gtkagg.o
    In file included from /opt/lang/python/include/python2.3/Python.h:8,
                     from /opt/app/gnome-2.4/include/pygtk-2.0/pygobject.h:5,
                     from src/_gtkagg.cpp:10:
    /opt/lang/python/include/python2.3/pyconfig.h:828:1: warning: "_FILE_OFFSET_BITS" redefined
    In file included from /usr/include/iso/string_iso.h:31,
                     from /usr/include/string.h:18,
                     from /opt/lang/gcc-3.3.2/include/c++/3.3.2/cstring:51,
                     from src/_gtkagg.cpp:1:
    /usr/include/sys/feature_tests.h:96:1: warning: this is the location of the previous definition
    In file included from /opt/lang/python/include/python2.3/Python.h:8,
                     from /opt/app/gnome-2.4/include/pygtk-2.0/pygobject.h:5,
                     from src/_gtkagg.cpp:10:
    /opt/lang/python/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" redefined
    In file included from /usr/include/iso/string_iso.h:31,
                     from /usr/include/string.h:18,
                     from /opt/lang/gcc-3.3.2/include/c++/3.3.2/cstring:51,
                     from src/_gtkagg.cpp:1:
    /usr/include/sys/feature_tests.h:142:1: warning: this is the location of the previous definition
    In file included from src/_gtkagg.cpp:10:
    /opt/app/gnome-2.4/include/pygtk-2.0/pygobject.h:140: error: parse error before
       `typename'
    /opt/app/gnome-2.4/include/pygtk-2.0/pygobject.h:147: error: parse error before
       `typename'
    error: command 'gcc' failed with exit status 1

Looking at the referenced pygobject.h file I see:

    139:    PyObject *(*enum_add)(PyObject *module,
    140:                      const char *typename,
    141:                      const char *strip_prefix,
    142:                      GType gtype);
    143:    PyObject* (*enum_from_gtype)(GType gtype, int value);
    144:    
    145:    PyTypeObject *flags_type;
    146:    PyObject *(*flags_add)(PyObject *module,
    147:                       const char *typename,
    148:                       const char *strip_prefix,
    149:                       GType gtype);
    150:    PyObject* (*flags_from_gtype)(GType gtype, int value);

It's not at all obvious to me what the problem is.

Has anyone else encountered this problem?  If so, do you have a workaround?

Thx,

-- 
Skip Montanaro
sk...@po...

>>>>> "N" == N Volbers <mit...@we...> writes:

    N> Hello list, I have just figured out how to use transformations
    N> for the 'Text' object from the class library to add a text to
    N> the graph (well actually this applies to any Artist object).

    N> If the coordinates are given as absolute _screen_ coordinates
    N> (very unlikely...), we use:

    N>   t = Text(x=x, y=y, text=text) 
    N>   axes.texts.append(t)

    N> If however the coordinates are given as _data_ coordinates x,y
    N> then we use:

    N>   t = Text(x=x, y=y, text=text) 
    N>   t.set_transform(axes.transData)
    N>   ax.texts.append(t)

You can also pass the transform as a kwarg

  t = Text(x=x, y=y, text=text, transform=axes.transData) 
  ax.texts.append(t)

    N> My question: Is there any transformation that would allow me to
    N> specify the coordinates as x,y tuple where (0,0) is bottom left
    N> and (1,1) is top right? In gnuplot this is known as the 'graph'
    N> coordinate system.

There are four built-in transforms that you should be aware of; below
ax is an Axes instance and fig is a Figure instance

  matplotlib.transforms.identity_transform()  # display coords
  ax.transData     # data coords
  ax.transAxes     # 0,0 is bottom,left of axes and 1,1 is top,right
  fig.transFigure  # 0,0 is bottom,left of figure and 1,1 is top,right

There is nothing wrong with instantiating Text instances yourself and
adding them to the figure or axes manually as you did, but both the
Axes and Figure have helper methods "text" which define a default
transformation that can be overridden

So

  t = Text(x=x, y=y, text=text) 
  t.set_transform(axes.transAxes)
  ax.texts.append(t)

is equivalent to 

  ax.text(x, y, text, transform=ax.transAxes) 

The default transform for ax.text is ax.transData and the default
transform for fig.text is fig.transFigure.

Of course, you can define more general transformations, eg
matplotlib.transforms.Affine, but the four listed above arise in a lot
of applications.

If you have time and inclination to write a transformations tutorial
for the wiki, that would be great.

Thanks,
JDH

Hello list,

I have just figured out how to use transformations for the 'Text' object 
from the class library to add a text to the graph (well actually this 
applies to any Artist object).

If the coordinates are given as absolute _screen_ coordinates (very 
unlikely...), we use:

  t = Text(x=x, y=y, text=text)
  axes.texts.append(t)

If however the coordinates are given as _data_ coordinates x,y then we use:

  t = Text(x=x, y=y, text=text)
  t.set_transform(axes.transData)
  axes.texts.append(t)

My question: Is there any transformation that would allow me to specify 
the coordinates as x,y tuple where (0,0) is bottom left and (1,1) is top 
right? In gnuplot this is known as the 'graph' coordinate system.

Best regards,

Niklas.

Humufr wrote:
>     Hello,
> 
> I think that there are a problem with matshow in the current matplotlib 
> cvs version:
> 
> m1 = zeros((12,12))
> matshow(m1,origin='upper')
> matshow(m1,origin='lower')
> 
> give me exactly the same result. The lower case is not working.

It's not a bug, it's a feature :)

In [19]: matshow?
Type:           function
Base Class:     <type 'function'>
String Form:    <function matshow at 0x411f1064>
Namespace:      Interactive
File:           /usr/lib/python2.3/site-packages/matplotlib/pylab.py
Definition:     matshow(*args, **kw)
Docstring:
     Display an array as a matrix in a new figure window.

     The origin is set at the upper left hand corner and rows (first dimension
     of the array) are displayed horizontally.  The aspect ratio of the figure
     window is that of the array, as long as it is possible to fit it within
     your screen with no stretching.  If the window dimensions can't accomodate
     this (extremely tall/wide arrays), some stretching will inevitably occur.

     Tick labels for the xaxis are placed on top by default.


Basically matshow hardcodes origin='lower', as the code shows:

     # imshow call: use 'lower' origin (we'll flip axes later)
     kw['origin'] = 'lower'

I thought the docstring was clear enough, by saying:

     The origin is set at the upper left hand corner and rows (first dimension
     of the array) are displayed horizontally.

but if you feel a more emphatic description is needed, let us know.

The intent of matshow is precisely to serve as an imshow wrapper with fixed 
origin at the top left for matrix-type displays.  It uses imshow under the 
hood, so it doesn't take  any fine control away from you, rather it is a 
specialized function for displaying arrays which are meant to be understood as 
matrices in the traditional linear algebra sense.

OTOH, if further functionality for it is desired, I'm sure patches would be 
welcome.  It serves my needs fairly well, but I'm sure it can always be improved.

Cheers,

f

    Hello,

I think that there are a problem with matshow in the current matplotlib 
cvs version:

m1 = zeros((12,12))
matshow(m1,origin='upper')
matshow(m1,origin='lower')

give me exactly the same result. The lower case is not working.

N.

Hi all,

Is there a simple way I might have missed out to :

1- use/build an inverse color map ?
2- use a logarithmic color map ?

I am aware that I could add the corresponding colormaps in the =
matplotlib.cm
module, but isn't there a smarter and simpler way ?

Cheers,

Aure

Nicolas,

Please check the postscript backend results regardless of whether the 
cntr.c change I suggested makes a difference or not; in fact, just try 
the different backend first.  You could also try the png backend with a 
different dpi setting. Looking again at your plot, it looks a bit like a 
rounding problem, and I don't see how that would arise in cntr.c.  It 
could still be a rendering problem and be related to the chunking; there 
might be rendering anomalies at the chunk boundaries.  Cntr.c itself is 
still the prime candidate, though.  The artifacts remind me somewhat of 
the bug I was working on; maybe in both cases, the tracing algorithm is 
turning left when it should turn right, or something like that.  It 
might be something like a "<" that should be a "<="...

Near the very bottom of the Bz and some other panels there are some 
spiky features, different from the blocky artifacts that make stripes 
near 0.3, etc.  Are the little spiky things in the data, or are they 
also artifacts?

Do the blocky artifacts correspond to your grid spacing--are they 
single-gridpoint offsets?

If you plot only a subdomain--a smaller range of x and y--do the 
artifacts remain?

Eric

> 
> Now, my first question is: notice the artifacts on the contours of Bz and I at 
> y=0.3 and y=0.55, and on the contours of Q for multiples values of y. These 
> doesn't come from data, as they disappear when zooming in. Do you know where 
> do they come from ? And, more importantly (to me), how to get rid of them ?

Hello John & NG,

    sorry about the code wrapping, I don't know what 
happens to my email... I have to attach it in a Python file in this 
email, because my WebMail always wraps badly the code.

Thank you for a 
pointer to the Wiki!

Andrea.



"Imagination Is The Only Weapon In The War Against Reality."

http://xoomer.virgilio.it/infinity77

Nicolas,

I don't remember seeing artifacts like those before.  Most likely they 
come from a bug in the basic contouring routine, cntr.c, which is 
derived with slight modifications from the routine gcntr.c in gist. 
Beyond that, its origins seem lost in the murky past.  It seems to be 
old, clever, complicated, and very hard to understand in detail.  A few 
months ago I spent quite a bit of time trying to track down another bug, 
and I failed.

It might be related to chunking.  In cntr.c, try changing line 1384
     long nchunk = 30; /* hardwired for now */

to a different value--say 50--and see if the artifacts change.  If they 
don't, verify that the artifacts are the same when the postscript 
backend is used.

Good free contouring routines, especially ones that do filled contours 
and handle data masks, seem remarkably hard to find.

Eric

> I'd like to ask you several questions related to a figure I've generated ; I 
> apologize in advance for the forthcoming messages, because I've chosen to 
> start a new thread for each question...
> 
> My figure is located at http://nicolasgirard.nerim.net/img/artifacts.png . 
> Beware that the file is quite large (over 400 kb).
> 
> Now, my first question is: notice the artifacts on the contours of Bz and I at 
> y=0.3 and y=0.55, and on the contours of Q for multiples values of y. These 
> doesn't come from data, as they disappear when zooming in. Do you know where 
> do they come from ? And, more importantly (to me), how to get rid of them ?
> 
> Cheers,
> Nicolas

Ok, ok, I'll leave the axis('scaled') in.
Glad to hear someone finds it useful.
It actually also works for subplots, I had forgotten I had already fixed=20
that.

I patched the backed_bases to add the postition to a history stack, but it=
=20
probably doesn't get called everywhere correctly (i.e., the current=20
views/position should also be put on the stack when the subplot size is=20
adjused I guess). But it works fine when scaling/panning figures in the new=
=20
toolbar. I'll post it as a patch.

If someone still thinks axis('scaled') is broken, after all the discussion=
=20
we've had, please repost so we can work it out.

Thanks, Mark

Well, third question related to my figure...

as you can see the first tick of the x axis of the colorbar for the last plot 
(\Omega) is labelled "-0.0".

How to prevent this and have the tick labelled simply as "0.0" ?

Cheers,
Nicolas

Hi again,

this is my second question related to the figure located at:
http://nicolasgirard.nerim.net/img/artifacts.png

The figure was generated using an instance of the following RunContour clas=
s:

class RunFigure:
    """ Une figure relative =E0 un unique run """
    def __init__(self,run):
        """ On sp=E9cifie le run, soit par son nombre nb, soit directement =
"""
        self.run =3D run
        # pour fichier de sortie
        self.plotname=3D'fig'
        self.dpi=3D150
        self.orientation=3D'portrait'
        self.figsize=3D(5,3)
        # Titre de la figure
        self.figtitle=3D"Run %04d - %s"%(self.run.nb,self.run.title)
    def plot(self):
        #gray()
        self.fig=3Dfigure(figsize=3Dself.figsize,dpi=3Dself.dpi)
    def filename(self):
        return '/home/ngirard/out/%04d_%s.png'%(self.run.nb,self.plotname)
    def save(self):
        gray()
        savefig(self.filename(),
                dpi=3Dself.dpi,orientation=3Dself.orientation)

class RunContour(RunFigure):
    def __init__(self,run,vals=3D['y1'],max=3DNone,**kwargs):
        RunFigure.__init__(self,run,**kwargs)
        #self.max =3D max or self.run.iz
        # pour fichier de sortie
        self.plotname=3D'cont'
        self.orientation =3D 'landscape'
        self.figsize=3D(11,7)
        r =3D self.run
        self.vals =3D [r.y[0],r.y[2],r.y[4],r.y[6],r.p,r.q,r.omega]
        self.valnames =3D [r"\rho",r"v_z",r"B_z",r"I",r"P",r"Q",r"\Omega"]
    def plot(self):
        RunFigure.plot(self)
        nbvals =3D len(self.vals)
        plotLocations =3D ["1%d%d"%(nbvals,i+1) for i in range(nbvals)]
        titles =3D [r"$%s$"%n for n in self.valnames]
        first=3DTrue
        for val in self.vals:
            plotLocation =3D plotLocations.pop(0)
            if first:
                ax1=3Dsubplot(plotLocation)
                ax1.xaxis.set_major_locator(LinearLocator(numticks=3D3))
                first=3DFalse
            else:
                ax =3Dsubplot(plotLocation,sharex=3Dax1,sharey=3Dax1)
                setp(ax.get_yticklabels(), visible=3DFalse)
                setp(ax.get_xticklabels(), visible=3DFalse)
            contourf(self.run.r,self.run.z,val,30)
            title(titles.pop(0),fontproperties=3Dsmall)
            cb =3D colorbar(orientation=3D'horizontal')
            cb.xaxis.set_major_locator(LinearLocator(numticks=3D3))


On to my question:
Note that I specified a linear locator for the x axis of the 1st plot, and =
for=20
the x axis of the colorbars using the same code:

   ooooooo.set_major_locator(LinearLocator(numticks=3D3))

However all colorbars ticks are formatted with a 2 digit precision whereas =
the=20
ticks of the 1st fig. xaxis are formatted with a 3 digit precision.=20

Why this discrepancy ?

PS: please don't hesitate to give me any advice to enhance the above code i=
f=20
you wish !

Thanks in advance,
Nicolas

Hi all,
I'd like to ask you several questions related to a figure I've generated ; I 
apologize in advance for the forthcoming messages, because I've chosen to 
start a new thread for each question...

My figure is located at http://nicolasgirard.nerim.net/img/artifacts.png . 
Beware that the file is quite large (over 400 kb).

Now, my first question is: notice the artifacts on the contours of Bz and I at 
y=0.3 and y=0.55, and on the contours of Q for multiples values of y. These 
doesn't come from data, as they disappear when zooming in. Do you know where 
do they come from ? And, more importantly (to me), how to get rid of them ?

Cheers,
Nicolas

>>>>> "andrea" == andrea gavana@tin it <and...@ti...> writes:

    andrea> I do these steps:

    andrea> def mouse_press(self, event):

You code is badly wrapped, which makes it really hard to read and
test.  Could you post again being careful to make sure that the lines
don't wrap?

Also, see the recent wiki entry "Interactive Plotting" which addresses
related issues, particularly picking points in a scatter plot.

JDH

Hello NG,

    in my app, I plot the position of some oil wells 
represented by dots in a x-y plot. The coordinates of the positions are 
integers. I use the command:

myaxes.plot(xc, yc, "ko")

where xc, yc 
are the wells' coordinates. After some calculations, I would like to do 
these 2 things in the most *efficient* or *intelligent* way:

1) 
Depending on the value of a certain parameter, every well (dot) should 
have a color (there are only 5 colors that a well may assume). For 
example, if this parameter has a value less than 0.1, a well is painted 
green, if it has a value greater than 0.1 but smaller than 1, a well is 
painted blue and so on. At the moment, the only way I can think about 
to implement such a thing is to do:

for ii in xrange(len(xc)):
    
axdata.plot([xc[i]], [yc[i]], 'ko')

which means defining a new Lines2D 
object for every well. Next, it is easier to assign a different colour 
to each well.

2) When the user presses the mouse "near" a well, I 
would like to be able to:
a) Verify that the mouse click was "really" 
near a well and not somewhere else, where there are no wells;
b) If a) 
is True, retrieving which wells was clicked (which Lines2D was 
clicked).

At the moment, using the plot command:

self.mp = myaxes.plot
(xc, yc, "ko")

I do these steps:

def mouse_press(self, event):

        # Check if the click is inside the axes
        if event.inaxes 
is None:
            return

        xvalue, yvalue = event.xdata, 
event.ydata

        # Round to integer the click coordinates
        
xc, yc = int(round(xvalue)), int(round(yvalue))
        
        # get 
xdata and ydata for all the wells
        xdata = self.mp[0][0].
get_xdata()
        ydata = self.mp[0][0].get_ydata()
        
        
if xc in xdata:
            # find which wells have X coordinates 
equals to xc
            indxs = [x[0] for x in enumerate(xdata) if x
[1] == xc]

            if yc in ydata:
                # find which 
wells have Y coordinates equals to yc
                indys = [x[0] for 
x in enumerate(ydata) if x[1] == yc]

                lenx = len(indxs)
                leny = len(indys)

                # create 2 lists 
that can be compared in length

                if lenx < leny:
                    indxs.extend([-9999]*(leny-lenx))
                
elif leny < lenx:
                    indys.extend([-9999]*(lenx-leny))

                tmp = []
                # find the intersections 
between the 2 lists 
                for xcoord in indxs:
                    if xcoord in indys:
                        tmp.
append(indys.index(xcoord))
                    
                # ==> 
The click matches the well if len(tmp) > 0
                if len(tmp) 
> 0:
                    ind = tmp[0]
                    # get 
wellnames from other sources
                    currentwell = self.
wellnames[indys[ind]]

Thank you for every suggestion. Great work with 
matplotlib!

Andrea.

John,

> Hey Sascha, thanks for this example.  If you get some time, could you
> add it to the matplotlib wiki at
> http://www.scipy.org/wikis/topical_software/MatplotlibCookbook?

It's been a pleasure. I have added my example (including your suggested 
changes) to the wiki: 
http://www.scipy.org/wikis/topical_software/MatplotlibAndZope

Sascha

> I have one suggestion: you need to be careful to do
>
> import matplotlib
> matplotlib.use('Agg')
>
> *before* importing pylab, in case the default matplotlibrc setting has
> a GUI backend (eg 'backend : GTKAgg')
>
> Thanks!
> JDH 

Hello, I'm using matplotlib 0.83.2 and I'm trying to get matplotlib to
work with py2exe. I am getting this error message in the *.exe.log file:
 
Traceback (most recent call last):
  File "SPC.py", line 6, in ?
  File "Frame1.pyc", line 10, in ?
  File "Frame2.pyc", line 9, in ?
  File "matplotlib\__init__.pyc", line 568, in ?
  File "matplotlib\__init__.pyc", line 261, in wrapper
  File "matplotlib\__init__.pyc", line 376, in _get_data_path
RuntimeError: Could not find the matplotlib data files
 
 
 
 
My setup.py is listed below:
 
 
 
 
#setup.py
from distutils.core import setup
import py2exe
 
# We need to import the glob module to search for all files.
import glob
 
# We need to exclude matplotlib backends not being used by this
executable.  You may find
# that you need different excludes to create a working executable with
your chosen backend.
opts = {
    'py2exe': { 'excludes': ['_gtkagg', '_tkagg'],
                'dll_excludes': ['libgdk-win32-2.0-0.dll',
                                 'libgobject-2.0-0.dll']
              }
       }
 
# Additional data files are required by matplotlib.  Note that the
glob.glob routine
# doesn't seem to pick up the .matplotlib resource file, so I copy that
separately.
setup(
    data_files = [('lib\matplotlibdata',
glob.glob(r'c:\python24\share\matplotlib\*')),
                  ('lib\matplotlibdata',
['c:\python24\share\matplotlib\matplotlibrc'])],
    name = 'demo',
    description = 'MatPlotLib Demo Program',
    windows = [{"script":"SPC.py", "icon_resources":[(0x001,
"mag.ico")]}]
    )
 
 
there are also lots of files that are excluded these are:
 
The following modules appear to be missing
['_xlrdutils', 'cephes', 'numerix.ArrayType', 'numerix.Complex',
'numerix.Float'
, 'numerix.Float32', 'numerix.Float64', 'numerix.Int', 'numerix.Int16',
'numerix
.Int32', 'numerix.Matrix', 'numerix.UInt8', 'numerix.absolute',
'numerix.add', '
numerix.alltrue', 'numerix.arange', 'numerix.arctan2', 'numerix.argmin',
'numeri
x.argsort', 'numerix.array', 'numerix.asarray', 'numerix.asum',
'numerix.ceil',
'numerix.clip', 'numerix.compress', 'numerix.concatenate',
'numerix.conjugate',
'numerix.convolve', 'numerix.cos', 'numerix.cumsum', 'numerix.diagonal',
'numeri
x.divide', 'numerix.dot', 'numerix.equal', 'numerix.exp',
'numerix.fft.fft', 'nu
merix.fft.inverse_fft', 'numerix.floor', 'numerix.greater',
'numerix.indices', '
numerix.less', 'numerix.log', 'numerix.log10', 'numerix.logical_and',
'numerix.m
atrixmultiply', 'numerix.maximum', 'numerix.minimum',
'numerix.mlab.amax', 'nume
rix.mlab.amin', 'numerix.mlab.cov', 'numerix.mlab.diff',
'numerix.mlab.flipud',
'numerix.mlab.hanning', 'numerix.mlab.rand', 'numerix.mlab.std',
'numerix.mlab.s
vd', 'numerix.multiply', 'numerix.nonzero', 'numerix.nx',
'numerix.ones', 'numer
ix.pi', 'numerix.power', 'numerix.put', 'numerix.ravel',
'numerix.repeat', 'nume
rix.reshape', 'numerix.resize', 'numerix.searchsorted', 'numerix.shape',
'numeri
x.sin', 'numerix.size', 'numerix.sometrue', 'numerix.sort',
'numerix.sqrt', 'num
erix.take', 'numerix.tan', 'numerix.transpose', 'numerix.where',
'numerix.which'
, 'numerix.zeros', 'matplotlib.numerix.absolute',
'matplotlib.numerix.equal', 'm
atplotlib.numerix.sqrt', 'numarray.Complex', 'numarray.Complex32',
'numarray.Com
plex64', 'numarray.Float', 'numarray.Float32', 'numarray.Float64',
'numarray.Int
', 'numarray.Int16', 'numarray.Int32', 'numarray.Int8',
'numarray.NumArray', 'nu
marray.UInt16', 'numarray.UInt32', 'numarray.UInt8', 'numarray.asarray',
'numarr
ay.fromlist', 'numarray.shape', 'numarray.typecode', 'numarray.zeros']
 
any ideas how I can fix this thing so that it can work?
 
Thanks!
 
Jeff
  _____  

Jeffrey Thomas Peery
SeaMetrics, Inc.
Mechanical Engineer 
Jef...@Se...
253.872.0285 (fax)
253.872.0284 (phone)
  _____  

 

>>>>> "Ken" == Ken McIvor <mc...@ii...> writes:

    Ken> John, I just submitted a (lightly tested) patch to
    Ken> sourceforge which tries to detect that wxPython.h is missing.
    Ken> This situation is handled the same way a missing `wx-config'
    Ken> is, in that the build is only killed when BUILD_WXAGG is True
    Ken> (as opposed to just emitting a message when it's "auto").

OK, I just committed this.  There was a minor correction

    flags = getoutput(wxconfig + ' --cppflags').split()
                                               ^^^^^^^^          
Checking in setupext.py;
/cvsroot/matplotlib/matplotlib/setupext.py,v  <--  setupext.py
new revision: 1.88; previous revision: 1.87


'Thanks, Kevin'.replace('vi', '')   <wink>

Thanks  Robert. I made the changes to texmanager.py and it worked.


On 08 Sep, 2005, at 23:24, Robert Kern wrote:

> Samuel M.Smith wrote:
>
>
>> With usetex = true, a serif font is used. How to I get matplotlib to
>> use a sans serif font?
>> I assume I need to change the font.latex.package but I don't know   
>> what
>> my choices are.
>>
>
> I don't think so. LaTeX font packages specify one each of serif,
> sans-serif, and typewriter faces[1]. The problem is that matplotlib's
> generated LaTeX doesn't seem to honor the font.family selection.
>
> You can add something like this at the top of  
> TexManager.get_tex_command():
>
> fontcmd = {'sans-serif': r'{\sffamily %s}',
>            'monospace': r'{\ttfamily %s}'}.get(rcParams 
> ['font.family'],
>                                                r'{\rmfamily %s}')
> tex = fontcmd % tex
>
> [1] But to find which font packages you have installed, go to
> /usr/local/share/texmf/tex/latex/ (replace /usr/local with whatever  
> the
> prefix is for your TeX installation; also "texmf" may be something
> similar like "texmf-dist" in DarwinPorts). Then
>
>   $ ls */*.fd
>
> I think all of those directories that have .fd files in them are font
> packages. The package name will be the same as the directory name, I
> believe.
>
> -- 
> Robert Kern
> rk...@uc...
>
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

**********************************************************************
Samuel M. Smith Ph.D.
2966 Fort Hill Road
Eagle Mountain, Utah 84043
801-768-2768 voice
801-768-2769 fax
**********************************************************************
"The greatest source of failure and unhappiness in the world is
giving up what we want most for what we want at the moment"
**********************************************************************

On Friday 09 September 2005 16:51, John Hunter wrote:
> >>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:
>
>     Nicolas> Nope... see lib/matplotlib/contour.py, current cvs
>     Nicolas> version, line 627.
>
> Sometimes, nondeveloper CVS lags behind developer access.  See revision
>
Oh, ok, I didn't know...

Nicolas

>>
>> However when I set usetex=True in my matplotlibrc file it does not
>> use tex. I have to manually call
>> rc('text',usetex=True) inside python, do you know why it does not
>> work from the rc file?
>>
>
> The only reason I can think of is that your rc file is stored where  
> mpl can't
> find it, or, you have another rc file somewhere that is being read  
> before the
> one you are editing.
>
>

When I switched from matplotlib 0.82 to 0.83.2 I had problems and had  
to revert back to 0.82 until I found
a fix for the problems. Everytime I installed 0.83.2 it would move  
my .matplotlibrc file into .matplotlib/matplotlibrc.
When I reinstalled 0.83.2 I had to manually move the rc file back out  
of the .matplotlibrc directory. I made a backup
of .matplotlibrc and stupidly called it matplotlibrc. It appears that  
0.83.2 will first look for matplotlibrc in your home directory and  
then if it doesn't find it there look for matplotlibrc in  
~/.matplotlib/matplotlibrc. Once I renamed the matplotlibrc in my  
home folder the changes I made to select tex in the ~/.matplotlib/ 
matplotlib showed up.

Thanks.

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:

    Nicolas> On Friday 09 September 2005 16:37, Jeff Whitaker wrote:
    >> Nicolas Girard wrote: >May I suggest that the documentation for
    >> contour() contains fmt='%1.3f' >instead of fmt='1.3f' ?
    >> 
    >> Someone beat me to it - it already reads that way in CVS.

    Nicolas> Nope... see lib/matplotlib/contour.py, current cvs
    Nicolas> version, line 627.

Sometimes, nondeveloper CVS lags behind developer access.  See revision

Checking in lib/matplotlib/contour.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/contour.py,v  <--  contour.py
new revision: 1.13; previous revision: 1.12

JDH

On Friday 09 September 2005 16:37, Jeff Whitaker wrote:
> Nicolas Girard wrote:
> >May I suggest that the documentation for contour() contains fmt='%1.3f'
> >instead of fmt='1.3f' ?
>
> Someone beat me to it - it already reads that way in CVS.

Nope... see lib/matplotlib/contour.py, current cvs version, line 627.

Nicolas