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

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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.

http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel--__--__--

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

https://lists.sourceforge.net/lists/listinfo/matplotlib-develEnd of Matplotlib-devel Digest