matplotlib-users Mailing List for matplotlib

Humufr wrote:
> 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.
That's precisely why matshow was written, to address the aspect/size problems 
of using imshow when a 'matrix display' was desired.
If you want something which is similar to matshow but tuned for your own 
purposes, I suggest you just copy the matshow source and start modifying it. 
It's a short function, so you shouldn't have problems.
Cheers,
f

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