matplotlib-devel Mailing List for matplotlib

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: 2004年5月10日 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: 2004年5月11日 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: 2004年5月11日 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...>; 2004年5月11日 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...>; 2004年5月11日 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: 2004年5月11日 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...>; 2004年5月11日 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...>; 2004年5月11日 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: 2004年5月11日 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: 2004年5月11日 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: 2004年5月11日 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: 2004年5月11日 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: 2004年5月11日 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: 2004年5月11日 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
>

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

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