array bug -fix

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?

JDH

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

···

On Tue, 2004-05-11 at 14:03, John Hunter wrote:

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 -0700

X-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.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:

>
> > 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...>