matplotlib-devel Mailing List for matplotlib (Page 2)

What you are seeing is one of the odd inconsistencies
present in Numeric regarding what kind of thing is returned
for a single element. This has been discussed on the numpy
list some years back.
>>> a = zeros((3,3), 'f')
>>> type(a[0,0])
<type 'array'>
>>> type(a[0][0])
<type 'float'>
>>> b = zeros((3,3), 'd')
>>> type(b[0,0])
<type 'float'>
>>> type(b[0][0])
<type 'float'>
So what kind of thing you get back when indexing a 2-d array
depends on both the type and dimensionality of the array.
The basic rule is that if the array is more than one dimension,
and not one of the basic python numerical types (e.g., 'f')
then indexing a single element tries to preserve the type by
returning a rank-0 array of the same type. Oddly though, indexing
a single element of a 1-d 'f' array returns a Python float scalar
(why the difference, I have no idea). This is why a[0][0] returns
something different than a[0,0] since one is indexing a 1-d array
(a[0]).
For numarray we decided that indexing a single element would always
return a Python scalar since that seemed to be what most expected.
There were those that argued that it should always return a rank-0
array, but we decided against that.
Perry
> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...]On Behalf Of rod
> holland
> Sent: Tuesday, May 11, 2004 4:59 PM
> To: mat...@li...
> Subject: [matplotlib-devel] problem with <type 'array'> in pcolor
> 
> 
> The following code 
> 
> ======================
> from matplotlib.matlab import *
> 
> x = arange(0,20,.2)
> y = arange(0,20,.2)
> X, Y = meshgrid(x,y)
> z=zeros((len(x),len(y)),'f')
> for i in enumerate(x):
> for j in enumerate(y):
> z[i[0]][j[0]]=10*sin(i[1]*j[1])
> #or z[i[0],j[0]]=10*sin(i[1]*j[1]) 
> pcolor(X,Y, transpose(z),shading='faceted')
> show()
> =======================
> 
> breaks in the module color.py
> 
> =============================
> def get_color(self, val, valmin, valmax):
> # map val to a range
> from 0 to 1
> if iterable(val):
> s = "val must be a scalar.
> Perhaps you meant to call get_colors?"
> #print val,type(val)
> raise ValueError, s
> #print valmin, valmax
> #print
> val,type(val)
> ind = self.indmax*(val-valmin)/(valmax-valmin)
> return
> self.rgbs[self._bound_ind(ind)]
> ==============================
> 
> because the test for iterable fails since the element C[i,j] is type
> <array>. One solution is to change the code section around line 1126 in
> axes.py from c = C[i,j] to the following. 
> 
> =====================
> for i in range(Nx-1):
> for j in range(Ny-1):
> 
> c = C[i][j]
> =======================
> 
> 
> the form C[i][j] seems to always return float.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

[The following problem seems to occur with Numeric but not with numarray]
The following code 
======================
from matplotlib.matlab import *
x = arange(0,20,.2)
y = arange(0,20,.2)
X, Y = meshgrid(x,y)
z=zeros((len(x),len(y)),'f')
for i in enumerate(x):
 for j in enumerate(y):
 z[i[0]][j[0]]=10*sin(i[1]*j[1])
 #or z[i[0],j[0]]=10*sin(i[1]*j[1]) 
pcolor(X,Y, transpose(z),shading='faceted')
show()
=======================
breaks in the module color.py
=============================
 def get_color(self, val, valmin, valmax):
 # map val to a range
from 0 to 1
 if iterable(val):
 s = "val must be a scalar.
Perhaps you meant to call get_colors?"
 #print val,type(val)
 raise ValueError, s
 #print valmin, valmax
 #print
val,type(val)
 ind = self.indmax*(val-valmin)/(valmax-valmin)
 return
self.rgbs[self._bound_ind(ind)]
==============================
because the test for iterable fails since the element C[i,j] is type
<array>. One solution is to change the code section around line 1126 in
axes.py from c = C[i,j] to the following. 
=====================
 for i in range(Nx-1):
 for j in range(Ny-1):
 c = C[i][j]
=======================
the form C[i][j] seems to always return float.

The following code 
======================
from matplotlib.matlab import *
x = arange(0,20,.2)
y = arange(0,20,.2)
X, Y = meshgrid(x,y)
z=zeros((len(x),len(y)),'f')
for i in enumerate(x):
 for j in enumerate(y):
 z[i[0]][j[0]]=10*sin(i[1]*j[1])
 #or z[i[0],j[0]]=10*sin(i[1]*j[1]) 
pcolor(X,Y, transpose(z),shading='faceted')
show()
=======================
breaks in the module color.py
=============================
 def get_color(self, val, valmin, valmax):
 # map val to a range
from 0 to 1
 if iterable(val):
 s = "val must be a scalar.
Perhaps you meant to call get_colors?"
 #print val,type(val)
 raise ValueError, s
 #print valmin, valmax
 #print
val,type(val)
 ind = self.indmax*(val-valmin)/(valmax-valmin)
 return
self.rgbs[self._bound_ind(ind)]
==============================
because the test for iterable fails since the element C[i,j] is type
<array>. One solution is to change the code section around line 1126 in
axes.py from c = C[i,j] to the following. 
=====================
 for i in range(Nx-1):
 for j in range(Ny-1):
 c = C[i][j]
=======================
the form C[i][j] seems to always return float.

On Tue, 2004年05月11日 at 14:03, John Hunter wrote:
> Rod sent me the email included below this off list. I was hoping to
> get some input from the numarray gurus. It's my thought that he
> should just be doing
> 
> z[i[0], j[0]]=10*sin(i[1]*j[1]) 
> 
> rather than
> 
> z[i[0]][j[0]]=10*sin(i[1]*j[1]) 
> 
> Is there a compelling argument either way?
I think the first form is preferred, because the z-indexing evaluates to
a single setitem. The second form creates a view of a row of z and then
does a setitem on it... it is less efficient as well as harder to read.
BTW, both forms worked for me. I got the impression that the first
form would fail. If it failed for you, what value do you have for
numarray.__version__?
Todd
> 
> JDH
> 
> 
> ______________________________________________________________________
> 
> From: rod holland <rh...@st...>
> To: John Hunter <jdh...@ac...>
> Subject: Re: [matplotlib-devel] array bug -fix
> Date: 11 May 2004 11:18:22 -0700
> 
> X-From-Line: rh...@st... Tue May 11 12:54:56 2004
> Return-Path: <rh...@st...>
> X-Original-To: jdh...@ac...
> Delivered-To: jdh...@ac...
> Received: from webperception.com (nitace [128.135.97.130])
> 	by ace.bsd.uchicago.edu (Postfix) with ESMTP id 76C3CEF21
> 	for <jdh...@ac...>; 2004年5月11日 12:54:55 -0500 (CDT)
> Received: from nt-home ([64.7.82.86])
> by webperception.com (WebPerception Mail Server) with SMTP id
> HRA74455
> for <jdh...@ac...>; 2004年5月11日 11:17:10 -0700
> Message-Id: <3.0...@ma...>
> X-Sender: rh...@ma...
> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
> Date: 2004年5月11日 11:18:22 -0700
> To: John Hunter <jdh...@ac...>
> From: rod holland <rh...@st...>
> Subject: Re: [matplotlib-devel] array bug -fix
> Lines: 82
> Xref: mother.paradise.lost mail-list.matplotlib-devel:322
> MIME-Version: 1.0
> 
> fixit note: John - take the bracket off transpose(z) - that was put in for
> testing. Once you make the change in C[i][j] you can add the bracket to
> force failure and test. I took the bracket off in the code below.
> 
> 
> If one forms a base array, for example, by using the ones or zeros
> functions with the float type ('f') in numeric (or numarray) (and then
> modfies elements wiht some loop - but this step really does not matter),
> each element in the array will have type <array> when called as you do in
> axes. Just give it a try. I do not know why this is the case - it may be
> because the element type (float) is part of the data type.
> 
> Here is a bit of code I tried that breaks your implementation:
> 
> from matplotlib.matlab import *
> 
> x = arange(0,20,.2)
> y = arange(0,20,.2)
> X, Y = meshgrid(x,y)
> z=zeros((len(x),len(y)),'f')
> for i in enumerate(x):
> for j in enumerate(y):
> z[i[0]][j[0]]=10*sin(i[1]*j[1]) 
> pcolor(X,Y, transpose(z),shading='faceted')
> show()
> 
> 
> The test for float occurs in color.py as follows:
> 
> def get_color(self, val, valmin, valmax):
> # map val to a range
> from 0 to 1
> if iterable(val):
> s = "val must be a scalar.
> Perhaps you meant to call get_colors?"
> #print val,type(val)
> raise ValueError, s
> #print valmin, valmax
> #print
> val,type(val)
> ind = self.indmax*(val-valmin)/(valmax-valmin)
> return
> self.rgbs[self._bound_ind(ind)]
> 
> 
> This breaks unless you form the element array value as C[i][j]. 
> 
> 
> At 06:41 AM 5/11/2004 -0500, you wrote:
> >>>>>> "rod" == rod holland <rh...@st...> writes:
> >
> > rod> lines 1123 - 1126 in axes.py should be changed at c = C[i,j]
> > rod> to the following. As it now stands a floating point number
> > rod> from a numeric array will generally register as type array
> > rod> rather than type float and be rejected as not iterable when
> > rod> later tested.
> >
> > rod> for i in range(Nx-1): for j in range(Ny-1):
> >
> > rod> c = C[i][j]
> >
> >
> >Sorry to be dense, but even after your detailed explanation I don't
> >really understand why you are getting an error. 
> >
> > * Are you passing a numerix array of floats for C? If so C[i,j]
> > should return the float we want
> >
> > * What do you mean will be "rejected as not iterable when later
> > tested"? I don't see any tests for iterable in poclor.
> >
> > * What is it you are doing differently that causes pcolor to fail
> > for you but not for the other uses, eg in pcolor_demo.py?
> >
> >If you could give me a little more information to clear up these
> >questions that would be helpful. Also, if you could post the
> >traceback you are getting that might help.
> >
> >Thanks!
> >John Hunter 
> >
-- 
Todd Miller <jm...@st...>

>>>>> "rod" == rod holland <rh...@st...> writes:
 rod> lines 1123 - 1126 in axes.py should be changed at c = C[i,j]
 rod> to the following. As it now stands a floating point number
 rod> from a numeric array will generally register as type array
 rod> rather than type float and be rejected as not iterable when
 rod> later tested.
 rod> for i in range(Nx-1): for j in range(Ny-1):
 rod> c = C[i][j]
Sorry to be dense, but even after your detailed explanation I don't
really understand why you are getting an error. 
 * Are you passing a numerix array of floats for C? If so C[i,j]
 should return the float we want
 * What do you mean will be "rejected as not iterable when later
 tested"? I don't see any tests for iterable in poclor.
 * What is it you are doing differently that causes pcolor to fail
 for you but not for the other uses, eg in pcolor_demo.py?
If you could give me a little more information to clear up these
questions that would be helpful. Also, if you could post the
traceback you are getting that might help.
Thanks!
John Hunter 

lines 1123 - 1126 in axes.py should be changed at c = C[i,j] to the
following. As it now stands a floating point number from a numeric array
will generally register as type array rather than type float and be
rejected as not iterable when later tested.
 for i in range(Nx-1):
 for j in range(Ny-1):
 c = C[i][j]

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
 Jeremy> Incidentally, two minor updates to the CVS version of
 Jeremy> backend_wx:
Hi Jeremy, good to hear from you. I'm glad you finally got all your
computer troubles sorted out.
Your install notes for OS X would actually be useful to others if
sourceforge could get their act together and actually archive the
lists (last archived entries early April - guess it's time for another
support request).
FYI, there are two places you should update after making CVS changes.
One is CHANGELOG, which miraculously, all the developers have been
good about updating, and the other is htdocs/goals.txt, which is a
kind of poor-man's structured text that is incorporated into the web
page http://matplotlib.sourceforge.net/goals.html so users can see
what is going on with their latest feature requests and bug fixes. I
know that the 2 you fixed were on there so it would be good to update
that page.
Thanks!
JDH

>>>>> "Timoth" == <ti...@co...> writes:
 Timoth> I have things like fontconfig installed in /usr/local, so
 Timoth> had to add /usr/local to the path (explaining the sed).
I think it is sensible to add /usr/local before /usr in the search
path - not sure why I didn't do it before.
 Timoth> I also have both pygtk1.2 (0.6.11) and pygtk2.2 (2.2.0),
 Timoth> including the header files. Since pygtk1.2 installs its
 Timoth> header files in /usr/local/include/pygtk, and pygtk2.2 in
 Timoth> /usr/local/include/pygtk-2.0, adding
 Timoth> /usr/local/include/pygtk-2.0 to the include path and then
 Timoth> including pygtk seems to pick up the pygtk1.2 header files
 Timoth> rather than the pygtk subdirectory of
 Timoth> /usr/local/include/pygtk-2.0 (explaining the mv's).
This surprises me, because pkg-config is supposed to handle this since
we explicitly ask for pygtk-2. Not sure how to handle this -
hopefully not too many folks have such an old pygtk installed!
 Timoth> Lastly, I needed to explicitly inform python distutils
 Timoth> that it is compiling c++ (explaining the CC=g++
 Timoth> environment variable).
Also surprising since distutils is supposed to detect the extension
and pick the right compiler. What version of python and gcc are you
using? Does it help to rename all the src/*.cpp files to *.cxx?
You'll have to edit setupext.py if you test this.
Thanks for the detailed notes,
JDH

Hi all,
It's been a long time since I've been able to do any work on Matplotlib 
- prompted (in part) by the demise of my trusty Debian box and its 
replacement by a Mac.
It took me a while to get a working Matplotlib installation, so I 
thought it may be worth documenting how I did it. Note that I have not 
bothered to install Gtk, so John will have to help with that one.
Mac OSX comes with a very nice (and fairly recent) native install of 
Python, so I elected to use that one.
First problem: no Numeric.
MacPython has some nice OXS 10.3 addons at:
http://ftp.cwi.nl/jack/python/mac/MacPython-Panther-2.3-2.dmg.
You probably want to use the package manager to install Numeric. Don't 
forget to install the source (or, if lazy, install the binaries, and 
copy arrayobject.h, f2c.h, ranlib.h and ufuncobject.h to 
System/Library/Frameworks/Python.framework/Versions/Current/include/ 
python2.3/Numeric
Next problem: no libpng.
Simple solution is to install libpng3 via Fink. The Matplotlib 
installer knows where to look for Fink packages, so no editing needed.
Incidentally, two minor updates to the CVS version of backend_wx:
* Toolbar now displays correctly on Mac OSX (MAC doesn't like having 
toolbar controls in a sizer, but wants to see them in a managed 
toolbar. Side effect of this is that the toolbar is at the top of the 
frame on OSX.
* Wx should now terminate the mainloop correctly when the last frame is 
closed.
Regards
Jeremy

Hi folks,
Firstly, congratulations on matplotlib - a great tool.
I thought I would share with you the problems I have had (and overcome) with installing matplotlib
on my computer (which runs Linux with many packages taken from source).
The short version, is that I could not simply run
 python setup.py build
but instead had to run:
 sed -e "s@.*linux2.*@ 'linux2' : ['/usr/local', '/usr',],@" setupext.py >newsetupext.py
 mv newsetupext.py setupext.py
 sudo mv /usr/local/include/pygtk /usr/local/include/pygtk-1.2
 CC=g++ python setup.py build
 sudo mv /usr/local/include/pygtk-1.2 /usr/local/include/pygtk
I have things like fontconfig installed in /usr/local, so had to add /usr/local to the path
(explaining the sed).
I also have both pygtk1.2 (0.6.11) and pygtk2.2 (2.2.0), including the header files. Since pygtk1.2
installs its header files in /usr/local/include/pygtk, and pygtk2.2 in /usr/local/include/pygtk-2.0,
 adding /usr/local/include/pygtk-2.0 to the include path and then including pygtk seems to pick up
the pygtk1.2 header files rather than the pygtk subdirectory of /usr/local/include/pygtk-2.0
(explaining the mv's).
Lastly, I needed to explicitly inform python distutils that it is compiling c++ (explaining the
CC=g++ environment variable).
So that this list is searchable, the kind of problems solved by the above were:
/usr/local/include/ft2build.h:56: freetype/config/ftheader.h: No such file or directory
src/ft2font.c: In function `newFT2FontObject':
src/ft2font.c:171: parse error before `*'
and an inability to use the GTKAgg backend because it was compiled against the wrong headers
(complaining at runtime that it could not import _gtk).
Anyway, I hope this is helpful to someone, and sorry if it has been discussed before etc (I only
have a slow dial-up link and browsing sourceforge mailing lists is painful.)
Tim Corbett-Clark.

On Tue, 2004年05月04日 at 17:33, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
> Todd> No, not yet. I was thinking about adding a minimal Matrix
> Todd> class to the numarray half of matplotlib.numerix for now.
> Todd> Then I'll add a more full-featured Matrix class to
> Todd> numarray-1.0. Does that sound OK?
> 
> Sounds great - all I need is Matrix multiplication -- cf,
> text.Text.get_rotation and text.Text._get_text_shift_and_size
> 
OK. I updated numerix to support Matrix multiplication for numarray.

John Hunter wrote:
> I factored matplotlib.text.Text instances and layouts out of the
> backends. Now matplotlib.text.Text does all the layout and passes the
> backends a *string* plus font properties etc. This simplifies the
> text handling on the backends considerably, which only need to know
> how to compute the width and height of an unrotated string. The
> frontend will then do the proper alignment for rotated text.
> 
[snip, snip]
> 
> Paul, I committed these changes after synching with your new font
> caching and there doesn't appear to be any problem; miraculously CVS
> seems to be working pretty well. I did some additional caching of AFM
> instances in backend_ps. You might want to rerun your ps profile
> script and see if the numbers improve further still.
Yes, the PS backend does appear to be about 30% faster. However, the Agg 
backend looks to be about 15% slower, so I guess there is a trade off here.
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Michael" == Michael J Salib <ms...@MI...> writes:
 Michael> Hi, I think I've found a bug in matplotlib 0.53. The bug
 Michael> can be triggered with the following commands
Fixed in the 0.53.1 bugfix release. Thanks for the report; let me
know if you have any more troubles!
Thanks,
JDH

Hi,
I think I've found a bug in matplotlib 0.53. The bug can be triggered
with the following commands
from matplotlib.matlab import *
plot(arange(40), array([1]*40))
show()
Basically, bad things happen if you try to plot a flat line. By
themselves, flat lines aren't very interesting, but they do occasionally
show up in the automated graphing batches I do. The first problem is an
easily patched bug in ticker.py where matplotlib tries to take the
logarithm of the interval span of the input data. For a constant data
series, that interval span is zero, and log(0) is naturally unhappy. 
Unfortunately, after fixing that problem, another problem arises. In
transformer.py, a divide by zero is triggered when trying to determine
display scale for much the same reason.
I've patched these bugs as best I can, but my fix isn't worth much since
the results look awful (no tick marks, data is uncentered). Its probably
best to let someone who knows what they're doing fix this for real.
Thanks a lot,
Mike Salib

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> No, not yet. I was thinking about adding a minimal Matrix
 Todd> class to the numarray half of matplotlib.numerix for now.
 Todd> Then I'll add a more full-featured Matrix class to
 Todd> numarray-1.0. Does that sound OK?
Sounds great - all I need is Matrix multiplication -- cf,
text.Text.get_rotation and text.Text._get_text_shift_and_size
JDH

On Tue, 2004年05月04日 at 14:32, John Hunter wrote:
> I factored matplotlib.text.Text instances and layouts out of the
> backends. Now matplotlib.text.Text does all the layout and passes the
> backends a *string* plus font properties etc. This simplifies the
> text handling on the backends considerably, which only need to know
> how to compute the width and height of an unrotated string. The
> frontend will then do the proper alignment for rotated text.
> 
> The benefits of these changes are
> 
> * simpler backends
> 
> * arbitrary rotated text layout works in agg, gd, and PS
> 
> * this lays the ground work for newline spearated text across
> backends since the layout will be on the front and the frontend
> can pass the backends newline split strings to render.
> 
> * the backend draw_text method is now is consistent with other
> backend methods, eg draw_lines, draw_rectangles. That is, the
> backends no nothing about matplotlib.Artists
> 
> KNOWN BUGS
> 
> * vertical text problem in PS to be fixed
> 
> This was a pretty comprehensive change so I recommend syncing your CVS
> tree.
> 
> Todd, I needed Numeric.Matrix to do the linear algebra for the
> rotations in the text module text. Is there a numarray equivalent
> that we can expose in numerix?
No, not yet. I was thinking about adding a minimal Matrix class to the
numarray half of matplotlib.numerix for now. Then I'll add a more
full-featured Matrix class to numarray-1.0. Does that sound OK?
Todd
> 
> Paul, I committed these changes after synching with your new font
> caching and there doesn't appear to be any problem; miraculously CVS
> seems to be working pretty well. I did some additional caching of AFM
> instances in backend_ps. You might want to rerun your ps profile
> script and see if the numbers improve further still.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Todd Miller <jm...@st...>

I factored matplotlib.text.Text instances and layouts out of the
backends. Now matplotlib.text.Text does all the layout and passes the
backends a *string* plus font properties etc. This simplifies the
text handling on the backends considerably, which only need to know
how to compute the width and height of an unrotated string. The
frontend will then do the proper alignment for rotated text.
The benefits of these changes are
 * simpler backends
 * arbitrary rotated text layout works in agg, gd, and PS
 * this lays the ground work for newline spearated text across
 backends since the layout will be on the front and the frontend
 can pass the backends newline split strings to render.
 
 * the backend draw_text method is now is consistent with other
 backend methods, eg draw_lines, draw_rectangles. That is, the
 backends no nothing about matplotlib.Artists
KNOWN BUGS
 * vertical text problem in PS to be fixed
This was a pretty comprehensive change so I recommend syncing your CVS
tree.
Todd, I needed Numeric.Matrix to do the linear algebra for the
rotations in the text module text. Is there a numarray equivalent
that we can expose in numerix?
Paul, I committed these changes after synching with your new font
caching and there doesn't appear to be any problem; miraculously CVS
seems to be working pretty well. I did some additional caching of AFM
instances in backend_ps. You might want to rerun your ps profile
script and see if the numbers improve further still.
JDH