Re: [matplotlib-devel] array bug -fix

[Todd M. <jm...@st...>]

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...>; 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 <jdh...@ac...>; Tue, 11 May 2004 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: Tue, 11 May 2004 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...>