matplotlib-devel Mailing List for matplotlib (Page 546)

I keep forgetting that unless the clf() is done, that
all the previous data elements are still present.
And thus the error will repeat. (Waiting for that
feature to allow autoclearing in interactive mode I guess)
Perry

after doing a clf(), it works. I thought I had started with
a clean session. Hmmm. I also notice that if I do something like
loglog(arange(10.), arange(10.)) I get an error as I should,
and then try againg with my first example, it still fails with
the same error message. Somehow it the first error causes it
to continue to fail unless clf() is performed.
Perry
 

I must be doing something stupid, but I can't get the simplest
loglog to work. For example:
>>> x = arange(10.) + 2
>>> y = x**2
>>> y
array([ 4., 9., 16., 25., 36., 49., 64., 81., 100.,
121.])
>>> loglog(x,y)
Traceback (most recent call last):
[...]
 xt = self.transx.positions(x)
 File "C:\Python23\Lib\site-packages\matplotlib\transforms.py", line 621,
in po
sitions
 return scale*(self.func(x)-minin) + self._boundout.min()
 File "C:\Python23\Lib\site-packages\matplotlib\transforms.py", line 520,
in lo
gwarn
 raise ValueError('Cannot take log of non-positive data')
ValueError: Cannot take log of non-positive data
>>>
Perry
(v0.53.1 on windows 2000)

I added a fast polygon drawing collection class and backend renderer
method. 
For large scatter plots (50000 points), the performance is 5 times
faster across all backends and 10 times faster for the *Agg backends.
Also, scatter works with many symbols: diamonds, sqaures, oriented
triangles, circles and more. Currently these are all regular polygons
but I can add more later when I finish general polygon collections and
line collections.
The scatter command returns a collection instance rather than a list
of patches as before. If you are setting properties on the return
values of scatter plots, you *may* need to change some code to use
methods appropriate for collections, though the user API is largely
compatible. See matplotlib.collections.
Also the size argument is now in points^2 (the area of the symbol in
points) and is not in data coords as before. This fixes a few
problems: symbols are not skewed by unequally shaped axes, scatter
works with log coords w/o distoring the symbol, and it is matlab
compatible.
The function scatter_classic is the old scatter function and will work
identically.
Let me know how this works with your scatter code, particularly if it
breaks it!
JDH

I just committed the changes I've been working on for the last week to
CVS. These include a new set of transformation classes in extension
code and a rewrite of all the artist constructors. The rational for
both is in the API_CHANGES file (part of CVS), which I'll include
below.
Please let me know if you can build the new code, and if it passes
your tests. There are still a few bugs to work out (known bugs
below). The major reason behind these changes was to implement fast
drawing of large collections of objects (lots of independent line
segments or polygons) using the new matplotlib.collections code (this
will support pcolor and scatter, not done yet). I haven't done
polygon collections yet, but my preliminary tests with line
collections indicate a 5-20x speed up for line collections of
1000-20000 lines. And these tests were before the new, hopefully much
faster, transform architecture was in place. After I get the rest of
the changes and fixes in I'll run some tests against 0.53.1 for
comparison.
These are the problems I know about
 -- data lim problem with image; see image_demo2
 -- handle space in roman/font mathtext
 -- scatter demos whacked
 -- fix minor text bboxing problems
 -- fix backend image area problem for vertical text in GTK
Also, I did a comprehensive rewrite of mathtext; here are my notes:
 factored ft2font stuff out of layout engine and defined an abstract
 class for font handling to lay groundwork for ps mathtext. I
 rewrote parser and made layout engine much more precise, fixing all
 the layout hacks. Added spacing commands \/ and \hspace. Added
 composite chars and defined angstrom.
The next release is likely to cause a pain for some due to the API
changes (mostly minor however and not in user space). But for the
first time, I'm fairly happy with the overall design and so I think
the API should be pretty stable for the forseeable future.
And here are the API changes notes 
API CHANGES in matplotlib-0.54
Autoscaling:
 The x and y axis instances no longer have autoscale view. These are
 handled by axes.autoscale_view
Axes creation:
 You should not instantiate your own Axes any more using the OO API.
 Rather, create a Figure as before and in place of
 f = Figure(figsize=(5,4), dpi=100)
 a = Subplot(f, 111)
 f.add_axis(a)
 use
 f = Figure(figsize=(5,4), dpi=100)
 a = f.add_subplot(111)
 That is, add_axis no longer exists and is replaced by 
 add_axes(rect, axisbg=defaultcolor, frameon=True)
 add_subplot(num, axisbg=defaultcolor, frameon=True)
Artist methods:
 If you define your own Artists, you need to rename the _draw method
 to draw
Bounding boxes. 
 matplotlib.transforms.Bound2D is replaced by
 matplotlib.transforms.Bbox. If you want to construct a bbox from
 left, bottom, width, height (the signature for Bound2D), use
 matplotlib.transforms.lbwh_to_bbox, as in 
 bbox = clickBBox = lbwh_to_bbox(left, bottom, width, height)
 The Bbox has a different API than the Bound2D. Eg, if you want to
 get the width and height of the bbox
 OLD
 width = self.figure.bbox.x.interval()
 height = self.figure.bbox.y.interval()
 New
 width = self.figure.bbox.width()
 height = self.figure.bbox.height()
Object constructors:
 You no longer pass the bbox, dpi, or transforms to the various
 Artist constructors. The old way or creating lines and rectangles
 was cumbersome because you had to pass so many attributes to the
 Line2D and Rectangle classes not related directly to the gemoetry
 and properties of the object. Now default values are added to the
 object when you call axes.add_line or axes.add_patch, so they are
 hidden from the user.
 If you want to define a custom transformation on these objects, call
 o.set_transform(trans) where trans is a Transformation instance.
 In prior versions of you wanted to add a custom line in data coords,
 you would have to do
 l = Line2D(dpi, bbox, x, y,
 color = color,
 transx = transx,
 transy = transy,	
 )
 now all you need is
 l = Line2D(x, y, color=color)
 and the axes will set the transformation for you (unless you have
 set your own already, in which case it will eave it unchanged)
Transformations:
 The entire transformation architecture has been rewritten.
 Previously the x and y transformations where stored in the xaxis and
 yaxis insstances. The problem with this approach is it only allows
 for separable transforms (where the x and y transformations don't
 depend on one another). But for cases like polar, they do. Now
 transformations operate on x,y together. There is a new base class
 matplotlib.transforms.Transformation and two concrete
 implemetations, matplotlib.transforms.SeparableTransformation and
 matplotlib.transforms.Affine. The SeparableTransformation is
 constructed with the bounding box of the input (this determines the
 rectangular coordinate system of the input, ie the x and y view
 limits), the bounding box of the display, and possibily nonlinear
 transformations of x and y. The 2 most frequently used
 transformations, data cordinates -> display and axes coordinates ->
 display are available as ax.transData and ax.transAxes. See
 alignment_demo.py which uses axes coords.
 Also, the transformations should be much faster now, for two reasons
 * they are written entirely in extension code
 * because they operate on x and y together, they can do the entire
 transformation in one loop. Earlier I did something along the
 lines of 
 xt = sx*func(x) + tx
 yt = sy*func(y) + ty
 Although this was done in numerix, it still involves 6 length(x)
 for-loops (the multiply, add, and function evaluation each for x
 and y). Now all of that is done in a single pass.
 
 See unit/transforms_unit.py for many examples using the new
 transformations.
 
 

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 

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
> 

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

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.

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

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

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]

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
 Jeremy> Incidentally, two minor updates to the CVS version of
 Jeremy> backend_wx:
Hi Jeremy, good to hear from you. I'm glad you finally got all your
computer troubles sorted out.
Your install notes for OS X would actually be useful to others if
sourceforge could get their act together and actually archive the
lists (last archived entries early April - guess it's time for another
support request).
FYI, there are two places you should update after making CVS changes.
One is CHANGELOG, which miraculously, all the developers have been
good about updating, and the other is htdocs/goals.txt, which is a
kind of poor-man's structured text that is incorporated into the web
page http://matplotlib.sourceforge.net/goals.html so users can see
what is going on with their latest feature requests and bug fixes. I
know that the 2 you fixed were on there so it would be good to update
that page.
Thanks!
JDH

>>>>> "Timoth" == <ti...@co...> writes:
 Timoth> I have things like fontconfig installed in /usr/local, so
 Timoth> had to add /usr/local to the path (explaining the sed).
I think it is sensible to add /usr/local before /usr in the search
path - not sure why I didn't do it before.
 Timoth> I also have both pygtk1.2 (0.6.11) and pygtk2.2 (2.2.0),
 Timoth> including the header files. Since pygtk1.2 installs its
 Timoth> header files in /usr/local/include/pygtk, and pygtk2.2 in
 Timoth> /usr/local/include/pygtk-2.0, adding
 Timoth> /usr/local/include/pygtk-2.0 to the include path and then
 Timoth> including pygtk seems to pick up the pygtk1.2 header files
 Timoth> rather than the pygtk subdirectory of
 Timoth> /usr/local/include/pygtk-2.0 (explaining the mv's).
This surprises me, because pkg-config is supposed to handle this since
we explicitly ask for pygtk-2. Not sure how to handle this -
hopefully not too many folks have such an old pygtk installed!
 Timoth> Lastly, I needed to explicitly inform python distutils
 Timoth> that it is compiling c++ (explaining the CC=g++
 Timoth> environment variable).
Also surprising since distutils is supposed to detect the extension
and pick the right compiler. What version of python and gcc are you
using? Does it help to rename all the src/*.cpp files to *.cxx?
You'll have to edit setupext.py if you test this.
Thanks for the detailed notes,
JDH

Hi all,
It's been a long time since I've been able to do any work on Matplotlib 
- prompted (in part) by the demise of my trusty Debian box and its 
replacement by a Mac.
It took me a while to get a working Matplotlib installation, so I 
thought it may be worth documenting how I did it. Note that I have not 
bothered to install Gtk, so John will have to help with that one.
Mac OSX comes with a very nice (and fairly recent) native install of 
Python, so I elected to use that one.
First problem: no Numeric.
MacPython has some nice OXS 10.3 addons at:
http://ftp.cwi.nl/jack/python/mac/MacPython-Panther-2.3-2.dmg.
You probably want to use the package manager to install Numeric. Don't 
forget to install the source (or, if lazy, install the binaries, and 
copy arrayobject.h, f2c.h, ranlib.h and ufuncobject.h to 
System/Library/Frameworks/Python.framework/Versions/Current/include/ 
python2.3/Numeric
Next problem: no libpng.
Simple solution is to install libpng3 via Fink. The Matplotlib 
installer knows where to look for Fink packages, so no editing needed.
Incidentally, two minor updates to the CVS version of backend_wx:
* Toolbar now displays correctly on Mac OSX (MAC doesn't like having 
toolbar controls in a sizer, but wants to see them in a managed 
toolbar. Side effect of this is that the toolbar is at the top of the 
frame on OSX.
* Wx should now terminate the mainloop correctly when the last frame is 
closed.
Regards
Jeremy

Hi folks,
Firstly, congratulations on matplotlib - a great tool.
I thought I would share with you the problems I have had (and overcome) with installing matplotlib
on my computer (which runs Linux with many packages taken from source).
The short version, is that I could not simply run
 python setup.py build
but instead had to run:
 sed -e "s@.*linux2.*@ 'linux2' : ['/usr/local', '/usr',],@" setupext.py >newsetupext.py
 mv newsetupext.py setupext.py
 sudo mv /usr/local/include/pygtk /usr/local/include/pygtk-1.2
 CC=g++ python setup.py build
 sudo mv /usr/local/include/pygtk-1.2 /usr/local/include/pygtk
I have things like fontconfig installed in /usr/local, so had to add /usr/local to the path
(explaining the sed).
I also have both pygtk1.2 (0.6.11) and pygtk2.2 (2.2.0), including the header files. Since pygtk1.2
installs its header files in /usr/local/include/pygtk, and pygtk2.2 in /usr/local/include/pygtk-2.0,
 adding /usr/local/include/pygtk-2.0 to the include path and then including pygtk seems to pick up
the pygtk1.2 header files rather than the pygtk subdirectory of /usr/local/include/pygtk-2.0
(explaining the mv's).
Lastly, I needed to explicitly inform python distutils that it is compiling c++ (explaining the
CC=g++ environment variable).
So that this list is searchable, the kind of problems solved by the above were:
/usr/local/include/ft2build.h:56: freetype/config/ftheader.h: No such file or directory
src/ft2font.c: In function `newFT2FontObject':
src/ft2font.c:171: parse error before `*'
and an inability to use the GTKAgg backend because it was compiled against the wrong headers
(complaining at runtime that it could not import _gtk).
Anyway, I hope this is helpful to someone, and sorry if it has been discussed before etc (I only
have a slow dial-up link and browsing sourceforge mailing lists is painful.)
Tim Corbett-Clark.

On Tue, 2004年05月04日 at 17:33, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
> Todd> No, not yet. I was thinking about adding a minimal Matrix
> Todd> class to the numarray half of matplotlib.numerix for now.
> Todd> Then I'll add a more full-featured Matrix class to
> Todd> numarray-1.0. Does that sound OK?
> 
> Sounds great - all I need is Matrix multiplication -- cf,
> text.Text.get_rotation and text.Text._get_text_shift_and_size
> 
OK. I updated numerix to support Matrix multiplication for numarray.

John Hunter wrote:
> I factored matplotlib.text.Text instances and layouts out of the
> backends. Now matplotlib.text.Text does all the layout and passes the
> backends a *string* plus font properties etc. This simplifies the
> text handling on the backends considerably, which only need to know
> how to compute the width and height of an unrotated string. The
> frontend will then do the proper alignment for rotated text.
> 
[snip, snip]
> 
> Paul, I committed these changes after synching with your new font
> caching and there doesn't appear to be any problem; miraculously CVS
> seems to be working pretty well. I did some additional caching of AFM
> instances in backend_ps. You might want to rerun your ps profile
> script and see if the numbers improve further still.
Yes, the PS backend does appear to be about 30% faster. However, the Agg 
backend looks to be about 15% slower, so I guess there is a trade off here.
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Michael" == Michael J Salib <ms...@MI...> writes:
 Michael> Hi, I think I've found a bug in matplotlib 0.53. The bug
 Michael> can be triggered with the following commands
Fixed in the 0.53.1 bugfix release. Thanks for the report; let me
know if you have any more troubles!
Thanks,
JDH

Hi,
I think I've found a bug in matplotlib 0.53. The bug can be triggered
with the following commands
from matplotlib.matlab import *
plot(arange(40), array([1]*40))
show()
Basically, bad things happen if you try to plot a flat line. By
themselves, flat lines aren't very interesting, but they do occasionally
show up in the automated graphing batches I do. The first problem is an
easily patched bug in ticker.py where matplotlib tries to take the
logarithm of the interval span of the input data. For a constant data
series, that interval span is zero, and log(0) is naturally unhappy. 
Unfortunately, after fixing that problem, another problem arises. In
transformer.py, a divide by zero is triggered when trying to determine
display scale for much the same reason.
I've patched these bugs as best I can, but my fix isn't worth much since
the results look awful (no tick marks, data is uncentered). Its probably
best to let someone who knows what they're doing fix this for real.
Thanks a lot,
Mike Salib

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> No, not yet. I was thinking about adding a minimal Matrix
 Todd> class to the numarray half of matplotlib.numerix for now.
 Todd> Then I'll add a more full-featured Matrix class to
 Todd> numarray-1.0. Does that sound OK?
Sounds great - all I need is Matrix multiplication -- cf,
text.Text.get_rotation and text.Text._get_text_shift_and_size
JDH

On Tue, 2004年05月04日 at 14:32, John Hunter wrote:
> I factored matplotlib.text.Text instances and layouts out of the
> backends. Now matplotlib.text.Text does all the layout and passes the
> backends a *string* plus font properties etc. This simplifies the
> text handling on the backends considerably, which only need to know
> how to compute the width and height of an unrotated string. The
> frontend will then do the proper alignment for rotated text.
> 
> The benefits of these changes are
> 
> * simpler backends
> 
> * arbitrary rotated text layout works in agg, gd, and PS
> 
> * this lays the ground work for newline spearated text across
> backends since the layout will be on the front and the frontend
> can pass the backends newline split strings to render.
> 
> * the backend draw_text method is now is consistent with other
> backend methods, eg draw_lines, draw_rectangles. That is, the
> backends no nothing about matplotlib.Artists
> 
> KNOWN BUGS
> 
> * vertical text problem in PS to be fixed
> 
> This was a pretty comprehensive change so I recommend syncing your CVS
> tree.
> 
> Todd, I needed Numeric.Matrix to do the linear algebra for the
> rotations in the text module text. Is there a numarray equivalent
> that we can expose in numerix?
No, not yet. I was thinking about adding a minimal Matrix class to the
numarray half of matplotlib.numerix for now. Then I'll add a more
full-featured Matrix class to numarray-1.0. Does that sound OK?
Todd
> 
> Paul, I committed these changes after synching with your new font
> caching and there doesn't appear to be any problem; miraculously CVS
> seems to be working pretty well. I did some additional caching of AFM
> instances in backend_ps. You might want to rerun your ps profile
> script and see if the numbers improve further still.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Todd Miller <jm...@st...>

I factored matplotlib.text.Text instances and layouts out of the
backends. Now matplotlib.text.Text does all the layout and passes the
backends a *string* plus font properties etc. This simplifies the
text handling on the backends considerably, which only need to know
how to compute the width and height of an unrotated string. The
frontend will then do the proper alignment for rotated text.
The benefits of these changes are
 * simpler backends
 * arbitrary rotated text layout works in agg, gd, and PS
 * this lays the ground work for newline spearated text across
 backends since the layout will be on the front and the frontend
 can pass the backends newline split strings to render.
 
 * the backend draw_text method is now is consistent with other
 backend methods, eg draw_lines, draw_rectangles. That is, the
 backends no nothing about matplotlib.Artists
KNOWN BUGS
 * vertical text problem in PS to be fixed
This was a pretty comprehensive change so I recommend syncing your CVS
tree.
Todd, I needed Numeric.Matrix to do the linear algebra for the
rotations in the text module text. Is there a numarray equivalent
that we can expose in numerix?
Paul, I committed these changes after synching with your new font
caching and there doesn't appear to be any problem; miraculously CVS
seems to be working pretty well. I did some additional caching of AFM
instances in backend_ps. You might want to rerun your ps profile
script and see if the numbers improve further still.
JDH