John,
I would be happy to try the beta code. And thank you for your helpful work.
Rod
Send Matplotlib-devel mailing list submissions to
matplotlib-devel@lists.sourceforge.netTo subscribe or unsubscribe via the World Wide Web, visit
matplotlib-devel List Signup and Options
or, via email, send a message with subject or body 'help' to
matplotlib-devel-request@lists.sourceforge.netYou can reach the person managing the list at
matplotlib-devel-admin@lists.sourceforge.netWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Matplotlib-devel digest..."Today's Topics:
1. array bug (rod holland)
2. Re: array bug (John Hunter)
3. Re: array bug -fix (John Hunter)
4. Re: array bug -fix (Todd Miller)
5. problem with <type 'array'> in pcolor (rod holland)
6. note: problem with <type 'array'> in pcolor (rod holland)
7. RE: problem with <type 'array'> in pcolor (Perry Greenfield)
8. RE: problem with <type 'array'> in pcolor (Perry Greenfield)
9. Re: problem with <type 'array'> in pcolor (John Hunter)--__--__--
Message: 1
Date: Mon, 10 May 2004 22:15:26 -0700
To: matplotlib-devel@lists.sourceforge.net
From: rod holland <rhh@...58...>
Subject: [matplotlib-devel] array buglines 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]
--__--__--
Message: 2
To: rod holland <rhh@...58...>
Cc: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] array bug
From: John Hunter <jdhunter@...5...>
Date: Tue, 11 May 2004 06:41:30 -0500> 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]
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--__--__--
Message: 3
To: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] array bug -fix
From: John Hunter <jdhunter@...5...>
Date: Tue, 11 May 2004 13:03:39 -0500--=-=-=
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 doingz[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?
JDH
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inlineX-From-Line: rhh@...58... Tue May 11 12:54:56 2004
Return-Path: <rhh@...58...>
X-Original-To: jdhunter@...5...
Delivered-To: jdhunter@...5...
Received: from webperception.com (nitace [128.135.97.130])
by ace.bsd.uchicago.edu (Postfix) with ESMTP id 76C3CEF21
for <jdhunter@...5...>; Tue, 11 May 2004 12:54:55 -0500 (CDT)
Received: from nt-home ([64.7.82.86])
by webperception.com (WebPerception Mail Server) with SMTP id
HRA74455
for <jdhunter@...5...>; Tue, 11 May 2004 11:17:10 -0700
Message-Id: <3.0.3.32.20040511111822.00fb3e28@...59...>
X-Sender: rhh@...59...
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 11 May 2004 11:18:22 -0700
To: John Hunter <jdhunter@...5...>
From: rod holland <rhh@...58...>
Subject: Re: [matplotlib-devel] array bug -fix
Lines: 82
Xref: mother.paradise.lost mail-list.matplotlib-devel:322
MIME-Version: 1.0fixit 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
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].
> 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]
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--=-=-=--
--__--__--
Message: 4
Subject: Re: [matplotlib-devel] array bug -fix
From: Todd Miller <jmiller@...31...>
To: John Hunter <jdhunter@...17...>
Cc: matplotlib-devel@lists.sourceforge.net
Date: 11 May 2004 15:24:27 -0400Rod 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 doingz[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 <rhh@...58...>
To: John Hunter <jdhunter@...5...>
Subject: Re: [matplotlib-devel] array bug -fix
Date: 11 May 2004 11:18:22 -0700X-From-Line: rhh@...58... Tue May 11 12:54:56 2004
Return-Path: <rhh@...58...>
X-Original-To: jdhunter@...5...
Delivered-To: jdhunter@...5...
Received: from webperception.com (nitace [128.135.97.130])
by ace.bsd.uchicago.edu (Postfix) with ESMTP id 76C3CEF21
for <jdhunter@...5...>; Tue, 11 May 2004 12:54:55 -0500 (CDT)
Received: from nt-home ([64.7.82.86])
by webperception.com (WebPerception Mail Server) with SMTP id
HRA74455
for <jdhunter@...5...>; Tue, 11 May 2004 11:17:10
-0700
ยทยทยท
At 08:04 PM 5/11/2004 -0700, you wrote:
At 06:41 AM 5/11/2004 -0500, you wrote:
On Tue, 2004-05-11 at 14:03, John Hunter wrote:Message-Id: <3.0.3.32.20040511111822.00fb3e28@...59...>
X-Sender: rhh@...59...
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 11 May 2004 11:18:22 -0700
To: John Hunter <jdhunter@...5...>
From: rod holland <rhh@...58...>
Subject: Re: [matplotlib-devel] array bug -fix
Lines: 82
Xref: mother.paradise.lost mail-list.matplotlib-devel:322
MIME-Version: 1.0fixit 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
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:
>
> > 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]
>
>
>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 <jmiller@...31...>--__--__--
Message: 5
Date: Tue, 11 May 2004 13:59:20 -0700
To: matplotlib-devel@lists.sourceforge.net
From: rod holland <rhh@...58...>
Subject: [matplotlib-devel] problem with <type 'array'> in pcolorThe 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
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.
--__--__--
Message: 6
Date: Tue, 11 May 2004 14:06:17 -0700
To: matplotlib-devel@lists.sourceforge.net
From: rod holland <rhh@...58...>
Subject: [matplotlib-devel] note: problem with <type 'array'> in pcolor[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
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.
--__--__--
Message: 7
From: "Perry Greenfield" <perry@...31...>
To: "rod holland" <rhh@...58...>,
<matplotlib-devel@lists.sourceforge.net>
Subject: RE: [matplotlib-devel] problem with <type 'array'> in pcolor
Date: Tue, 11 May 2004 17:38:03 -0400What 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: matplotlib-devel-admin@lists.sourceforge.net
[mailto:matplotlib-devel-admin@lists.sourceforge.net]On Behalf Of rod
holland
Sent: Tuesday, May 11, 2004 4:59 PM
To: matplotlib-devel@lists.sourceforge.net
Subject: [matplotlib-devel] problem with <type 'array'> in pcolorThe 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
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.
Oracle Berkeley DB Downloads
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options--__--__--
Message: 8
From: "Perry Greenfield" <perry@...31...>
To: <matplotlib-devel@lists.sourceforge.net>
Subject: RE: [matplotlib-devel] problem with <type 'array'> in pcolor
Date: Tue, 11 May 2004 20:36:19 -0400Rod Holland wrote:
Thanks for the reply. So matplotlib should probably call numarray, huh.
Well I would like it to, but realistcally, there are many reasons
people still need to use Numeric (scipy being one).How are you handling this transition time? I assume Numeric is being
imported rather than numarray or is something going on in disutils that
checks first for numarray and then defaults to numeric if not present?Numeric is loaded by default unless you set one of the ways of
making numarray the default (it's described on the matplotlib
web site (see http://matplotlib.sourceforge.net/faq.html#NUMARRAY
thought the link to the numerix page doesn't work for me at the
moment)If not, do you agree that the code should change so that it works
in either
case?I'll leave it to John to decide on that, but it would seem so
(though I don't know how many similar cases there are in the
code like this; it may suggest a utility function to coerce
rank-0 arrays to scalars or some such thing).Perry
--__--__--
Message: 9
To: "Perry Greenfield" <perry@...31...>
Cc: <matplotlib-devel@lists.sourceforge.net>
Subject: Re: [matplotlib-devel] problem with <type 'array'> in pcolor
From: John Hunter <jdhunter@...5...>
Date: Tue, 11 May 2004 20:38:12 -0500>> How are you handling this transition time? I assume Numeric is
>> being imported rather than numarray or is something going on in
>> disutils that checks first for numarray and then defaults to
>> numeric if not present?
> Numeric is loaded by default unless you set one of the ways
> of making numarray the default (it's described on the
> matplotlib web site (see
> http://matplotlib.sourceforge.net/faq.html#NUMARRAY thought
> the link to the numerix page doesn't work for me at the
> moment)I updated the link - thanks for letting me know. The correct link is
http://matplotlib.sourceforge.net/matplotlib.numerix.html.
>> If not, do you agree that the code should change so that it
>> works in either case?
> I'll leave it to John to decide on that, but it would seem
> so (though I don't know how many similar cases there are in
> the code like this; it may suggest a utility function to
> coerce rank-0 arrays to scalars or some such thing).I think having code that works if both cases would be a good thing,
but the caveat, as Todd mentioned, is that x[i][j] is slower than
x[i,j], and pcolor is already damn pokey. Fortunately, the point is
effectively moot. The changes I'm making now for fast drawing of
large numbers of patch objects will change the pcolor code
substantially. When I make those changes, it is unlikely that I will
loop over every i,j element separately, since this is painfully slow.Rod, If you'd like, I can email you a beta testing version of the next
release and you can see if it passes your test cases. If not, I'll
try and correct the problems.JDH
--__--__--
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and OptionsEnd of Matplotlib-devel Digest