Menu
▾
▴
[matplotlib-devel] Re: Matplotlib-devel digest, Vol 1 #77 - 9 msgs
|
From: rod h. <rh...@st...> - 2004-05-12 06:58:37
|
John, I would be happy to try the beta code. And thank you for your helpful work. Rod At 08:04 PM 5/11/2004 -0700, you wrote: >Send Matplotlib-devel mailing list submissions to > mat...@li... > >To 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 > mat...@li... > >You can reach the person managing the list at > mat...@li... > >When 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: mat...@li... >From: rod holland <rh...@st...> >Subject: [matplotlib-devel] array bug > >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] > > >--__--__-- > >Message: 2 >To: rod holland <rh...@st...> >Cc: mat...@li... >Subject: Re: [matplotlib-devel] array bug >From: John Hunter <jdh...@ac...> >Date: Tue, 11 May 2004 06:41:30 -0500 > >>>>>> "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 > > >--__--__-- > >Message: 3 >To: mat...@li... >Subject: Re: [matplotlib-devel] array bug -fix >From: John Hunter <jdh...@ac...> >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 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 > > >--=-=-= >Content-Type: message/rfc822 >Content-Disposition: inline > >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 >> > > >--=-=-=-- > > >--__--__-- > >Message: 4 >Subject: Re: [matplotlib-devel] array bug -fix >From: Todd Miller <jm...@st...> >To: John Hunter <jdh...@ni...> >Cc: mat...@li... >Date: 11 May 2004 15:24:27 -0400 > >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...> > > > >--__--__-- > >Message: 5 >Date: Tue, 11 May 2004 13:59:20 -0700 >To: mat...@li... >From: rod holland <rh...@st...> >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. > > > >--__--__-- > >Message: 6 >Date: Tue, 11 May 2004 14:06:17 -0700 >To: mat...@li... >From: rod holland <rh...@st...> >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 > #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. > > > >--__--__-- > >Message: 7 >From: "Perry Greenfield" <pe...@st...> >To: "rod holland" <rh...@st...>, > <mat...@li...> >Subject: RE: [matplotlib-devel] problem with <type 'array'> in pcolor >Date: Tue, 11 May 2004 17:38:03 -0400 > >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 >> > > >--__--__-- > >Message: 8 >From: "Perry Greenfield" <pe...@st...> >To: <mat...@li...> >Subject: RE: [matplotlib-devel] problem with <type 'array'> in pcolor >Date: Tue, 11 May 2004 20:36:19 -0400 > >Rod 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" <pe...@st...> >Cc: <mat...@li...> >Subject: Re: [matplotlib-devel] problem with <type 'array'> in pcolor >From: John Hunter <jdh...@ac...> >Date: Tue, 11 May 2004 20:38:12 -0500 > >>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: > > >> 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? > > Perry> Numeric is loaded by default unless you set one of the ways > Perry> of making numarray the default (it's described on the > Perry> matplotlib web site (see > Perry> http://matplotlib.sourceforge.net/faq.html#NUMARRAY thought > Perry> the link to the numerix page doesn't work for me at the > Perry> 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? > > Perry> I'll leave it to John to decide on that, but it would seem > Perry> so (though I don't know how many similar cases there are in > Perry> the code like this; it may suggest a utility function to > Perry> 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 >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > >End of Matplotlib-devel Digest > |
