matplotlib-devel Mailing List for matplotlib

On May 27, 2004, at 10:31 AM, John Hunter wrote:
> Another thing that might be useful for SVG is to add grouping
> elements. Eg, in axes.draw we could add
>
> def draw(...)
>
> renderer.begin_group('axes')
> ..plot a bunch of stuff
> renderer.end_group('axes')
Not that I have any clue how it's implemented, but Adobe Illustrator 
somehow does this in (E)PS, and PDF formats. It would be so cool if 
matplotlib achieved this, too.
But, as matplotlib gets better and better, that becomes less and less 
necessary.
Cheers!
Andrew

Jared Wahlstrand wrote:
> Here's a more complete version. It works with matplotlib-0.54 now, and
> I've tested it with a few of the example scripts, though I'm sure there
> are bugs. It doesn't do images or mathtext yet.
> 
> I found out that Inkscape doesn't support clipping yet, so it's sort of
> useless right now for some plots. The viewer I used to test the backend
> was the Adobe SVG plugin, which is available for lots of platforms:
> http://www.adobe.com/svg/
> 
> It still might be useful to implement PolygonCollections, because it
> might decrease the file size if, for the markers, we define a shape with
> its properties, and then just translate it to make copies. I also just
> noticed the 'marker' element, which looks promising.
Nice work. This was on my ToDo list, but it looks like you beat me to it. I'll
try running it through its paces in the next few days to how it does.
Does this backend use the font_manager to find fonts or does it use the viewers
font manager. They are both based on the same principles, but the viewer may do
a better job, so you might want to consider by-passing the font-manager.
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:
 Jared> Here's a more complete version. It works with
 Jared> matplotlib-0.54 now, and I've tested it with a few of the
 Jared> example scripts, though I'm sure there are bugs. It
 Jared> doesn't do images or mathtext yet.
I just tried it and actually got simple_plot to work - excellent!
I'm about to do a bug fix release of 0.54. Would you like to release
the code under the matplotlib license? If so I'll include it, but
hold off on announcing it until you are ready.
Another thing that might be useful for SVG is to add grouping
elements. Eg, in axes.draw we could add 
def draw(...)
 renderer.begin_group('axes')
 ..plot a bunch of stuff
 renderer.end_group('axes')
backend renderers that don't support groupings could just pass on
these calls, but for those who do, like svg, we could add the
appropriate grouping commands. Ditto for legends, axis, etc. This
might help the matplotlib svg output play nicely with svg editors.
JDH

Here's a more complete version. It works with matplotlib-0.54 now, and
I've tested it with a few of the example scripts, though I'm sure there
are bugs. It doesn't do images or mathtext yet.
I found out that Inkscape doesn't support clipping yet, so it's sort of
useless right now for some plots. The viewer I used to test the backend
was the Adobe SVG plugin, which is available for lots of platforms:
http://www.adobe.com/svg/
It still might be useful to implement PolygonCollections, because it
might decrease the file size if, for the markers, we define a shape with
its properties, and then just translate it to make copies. I also just
noticed the 'marker' element, which looks promising.
Jared

John,
> Would it suffice for you if there was an axes method clear_patches
> that simply removed all the previous patches you instantiated? The
> reason I ask is because it is not good practice to write scripts
> around private attributes which may disappear in a month.
It will be great - maybe just a "clipping" value set for an axes.
In my case:
	ax.set_clip(60)
Thanks
Leon

>>>>> "Leon" == Leon Brits <leo...@ne...> writes:
 Leon> I have noticed that there are 10 entries made to the
 Leon> 'patches'-data for every bargraph I add. Can you explain
 Leon> this - and/or possibly direct me to a page to read up more
 Leon> about "_patches".
Sure. There are only a few types of objects in matplotlib that appear
on the canvas: lines, patches, text and images. patches are things
that take up area, like circles and rectangles; the term is borrowed
from matlab. Commands like scatter, hist and bar instantiate the kind
of patch you need (eg Rectangle or RegularPolygon, both of which
derive from the Patch base class in matplotlib.patches) and add it to
the axes via Axes.add_patch. The list of patches that have been added
to the Axes are stored in a (private) variable self._patches which was
not intended to be manipulated by the user (hence the leading
underscore and my reference to the solution as a hack).
The question is: for dynamic graphs, what is the proper interface to
allow you to control, clear, etc, the patches that have been created?
The typical way one does dynamic graphs is to fix the objects (be they
lines, text or patches) and change the data attributes of those
objects (eg x and y locations, height). But your is a special case
because there is a fair amount of logic involved in getting the
attributes right for stacked bar graphs so it is probably easier to
clear the previous patches and add new ones.
Would it suffice for you if there was an axes method clear_patches
that simply removed all the previous patches you instantiated? The
reason I ask is because it is not good practice to write scripts
around private attributes which may disappear in a month.
JDH

>>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:
 Jared> Hi, I wanted to be able to use Inkscape to fiddle with the
 Jared> details of my plot before exporting it to postscript, so I
 Jared> started writing an SVG backend. What I have so far is
 Jared> attached. Note that it's based on matplotlib-0.53.1, so it
 Jared> won't work with 0.54 yet. So far it just draws lines,
 Jared> rectangles, polygons, and text (only in helvetica).
 Jared> Before I go further, I wanted to make sure you or someone
 Jared> else is not already working on this. If not, I'll port it
 Jared> to use font-caching, the new transform stuff and figure out
 Jared> how to draw arcs and polygon collections, etc.
This is absolutely great news! Glad to hear you made it so far on
your own. I CCd the devel list, which you may want to join, in case
anyone else has any advice for you. As far as I know, noone else is
working on this.
Here are a few thoughts for you when porting to 0.54.
All the text layout has been moved to the text.Text front end. So you
no longer need to worry about horizontal alignment and the like,
compute_offsets is no longer needed, etc.. You also do not need to
provide the window extent of text anymore. Just provide
 get_text_width_height(self, s, prop, ismath)
where s is a string and prop is a FontProperties instance. This
returns the width and height of the *unrotated* string. In the front
end I use this to compute the width and height of the rotated string,
compute the alignment offsets, and pass the x,y location to you to
draw the rotated string in draw_text. Instead of working with Text
instances, as in 0.53, you now work with strings and font properties.
The other new Renderer method is 
 get_canvas_width_height
As for polygon collections, you can implement this if you want, but
the base class provides an implementation that is reasonably fast
(approx 5x faster than the prior method of using separate polygon
instances). This may be good enough, since my guess is for most cases
you only demand the highest performance for interactive use, eg with
one of the GUI backends. So the *Agg backends implement this in
extension code. 
As for draw_arc, currently this is only used for drawing circles, so
if you implemented draw_circle there is would suffice.
 Jared> The fact that I, a python novice, could get so far in a day
 Jared> attests to the awesomeness of matplotlib. Thanks!
A day... Amazing. Maybe we'll have you write the PDF backend next :-)
JDH
from __future__ import division
from cStringIO import StringIO
from matplotlib.afm import AFM
from matplotlib.backend_bases import RendererBase, GraphicsContextBase,\
 FigureManagerBase, FigureCanvasBase
from matplotlib.cbook import iterable, is_string_like, flatten, enumerate,\
 get_recursive_filelist, True, False
from matplotlib.figure import Figure
from matplotlib.font_manager import fontManager
from matplotlib.ft2font import FT2Font
from matplotlib._matlab_helpers import Gcf
from matplotlib.text import Text
from matplotlib.transforms import Bound1D, Bound2D, Transform
from matplotlib import rcParams
from matplotlib.numerix import fromstring, UInt8, Float32
import binascii
import sys,os
def error_msg_svg(msg, *args):
 print >>sys.stderr, 'Error:', msg
 sys.exit()
def _nums_to_str(seq, fmt='%1.3f'):
 return ' '.join([_int_or_float(val, fmt) for val in seq])
def draw_if_interactive():
 pass
def show():
 """
 Show all the figures and enter the gtk mainloop
 This should be the last line of your script
 """
 for manager in Gcf.get_all_fig_managers():
 manager.figure.realize()
def new_figure_manager(num, *args):
 thisFig = Figure(*args)
 canvas = FigureCanvasSVG(thisFig)
 manager = FigureManagerSVG(canvas, num)
 return manager
def _rgb_to_hex(rgb):
 rgbhex='#'
 for c in rgb:
 h=hex(int(c*255))[2:]
 if len(h) < 2:
 h='0'+ h
 rgbhex += h
 return rgbhex
class RendererSVG(RendererBase):
 def __init__(self, svgwriter,width,height):
 self._svgwriter = svgwriter
 self.width=width
 self.height=height
 def flipy(self):
 'return true if y small numbers are top for renderer'
 return False
 def draw_rawsvg(self, svg):
 self._svgwriter.write(svg)
 def compute_text_offsets(self, t):
 """
 Return the (x,y) offsets to adjust for the alignment
 specifications
 """
 prop = t.get_font_properties()
 font = AFM(file(fontManager.findfont(prop, fontext='afm')))
 text = t.get_text()
 l,b,w,h = font.get_str_bbox(text)
 fontsize = prop.get_size_in_points()
 w *= 0.001*fontsize
 h *= 0.001*fontsize
 halign = t.get_horizontalalignment()
 valign = t.get_verticalalignment()
 if t.get_rotation()=='vertical':
 w, h = h, w
 if halign=='center': offsetx = w/2
 elif halign=='right': offsetx = 0
 else: offsetx = w
 
 if valign=='center': offsety = h/2
 elif valign=='top': offsety = h
 else: offsety = 0
 else:
 if halign=='center': offsetx = -w/2
 elif halign=='right': offsetx = -w
 else: offsetx = 0
 if valign=='center': offsety = h/2
 elif valign=='top': offsety = h
 else: offsety = 0
 
 return (offsetx, offsety)
 def draw_arc(self, gc, rgbFace, x, y, width, height, angle1, angle2):
 pass
 def draw_line(self, gc, x1, y1, x2, y2):
 """
 Draw a single line from x1,y1 to x2,y2
 """
 type = '<path '
 details = ' d=\"M %f,%f L %f,%f\" ' % (x1,self.height-y1,x2,self.height-y2)
 self._draw_svg(type, details, gc, None)
 def draw_lines(self, gc, x, y):
 """
 x and y are equal length arrays, draw lines connecting each
 point in x, y
 """
 if len(x)==0: return
 if len(x)!=len(y): error_msg_svg('x and y must be the same length')
 type = '<path '
 details =' d=\"M %f,%f ' % (x[0], self.height-y[0])
 for tup in zip(x[1:], self.height-y[1:]):
 details += 'L %f,%f ' % tup
 details += '\" '
 self._draw_svg(type, details, gc, None)
 def draw_rectangle(self, gc, rgbFace, x, y, width, height):
 rgbhex='fill:#'
 for c in rgbFace:
 rgbhex += hex(int(c*255))[2:]
 type = '<rect '
 details = """
 width=\"%f\"
 height=\"%f\"
 x=\"%f\"
 y=\"%f\" """ % (width, height, x, self.height-y-height)
 self._draw_svg(type, details, gc, rgbFace)
 def draw_polygon(self, gc, rgbFace, points):
 type = '<polygon '
 details = 'points =\"'
 for point in points:
 details += '%f,%f ' % (point[0],self.height-point[1])
 details += '\"'
 self._draw_svg(type, details, gc, rgbFace)
 def draw_text(self, gc, x, y, t):
 """
 draw a Text instance
 """
 prop = t.get_font_properties()
 font = AFM(file(fontManager.findfont(prop, fontext='afm')))
 
 text = t.get_text()
 l,b,w,h = font.get_str_bbox(text)
 if text=='': return
 ox, oy = self.compute_text_offsets(t)
 if t.get_rotation()=='vertical':
 x = x+ox
 y = self.height - y+oy-0.001*h
 else:
 x = x+ox
 y = self.height - y+oy
 thetext = '%s' % text
 fontname = font.get_fontname()
 fontsize = prop.get_size_in_points()
 if t.get_rotation()=='vertical':
 rotate = '90 rotate'
 else:
 rotate = ''
 svg = '<text '
 svg += """\
 x=\"%f\"
 y=\"%f\"
 style=\"font-size:%f;stroke-width:1.0000000pt;font-family:helvetica;\" >
 """ % (x,y,float(fontsize))
 svg += thetext+' </text>'
 self.draw_rawsvg(svg)
 def get_svg(self):
 return self._svgwriter.getvalue()
 def finish(self):
 self._svgwriter.write('</svg>')
 def new_gc(self):
 return GraphicsContextSVG()
 def get_text_extent(self, t):
 x, y = t.get_xy_display()
 prop = t.get_font_properties()
 font = AFM(file(fontManager.findfont(prop, fontext='afm')))
 
 text = t.get_text()
 l,b,w,h = font.get_str_bbox(text)
 fontsize = prop.get_size_in_points()
 l *= 0.001*fontsize
 b *= 0.001*fontsize
 w *= 0.001*fontsize
 h *= 0.001*fontsize
 ox, oy = self.compute_text_offsets(t)
 left = x+ox+l
 bottom = y-oy+b
 if t.get_rotation()=='vertical':
 w,h = h,w
 return Bound2D(left, bottom, w, h)
 def _draw_svg(self, type, details, gc, rgbFace):
 svg=type
 if rgbFace is not None:
 rgbhex='fill:#'
 for c in rgbFace:
 rgbhex += hex(int(c*255))[2:]
 rgbhex += ';'
 
 else:
 rgbhex='fill:none;'
 style = self._get_gc_props_svg(gc)
 svg+=style+rgbhex+ ' \"\n'
 svg += details
 svg += ' />\n'
 self._svgwriter.write(svg)
 def _get_gc_props_svg(self, gc):
 color='stroke:'+_rgb_to_hex(gc.get_rgb())+';'
 linewidth = 'stroke-width:'+repr(gc.get_linewidth())+'pt;'
 join = 'stroke-linejoin:'+gc.get_joinstyle()+';'
 cap = 'stroke-linecap:'+gc.get_capstyle()+';'
 offset, seq = gc.get_dashes()
 if seq is not None:
 dashes = 'stroke-dasharray:'
 for s in seq:
 dashes += '%d ' % s
 dashes += ';'
 dashes += 'stroke-dashoffset:%f;' % offset
 else:
 dashes = ''
 style = 'style=\"'+color+linewidth+join+cap+dashes
 return style
class GraphicsContextSVG(GraphicsContextBase):
 def set_linestyle(self, style):
 GraphicsContextBase.set_linestyle(self, style)
 offset, dashes = self._dashd[style]
 self.set_dashes(offset, dashes)
class FigureCanvasSVG(FigureCanvasBase):
 def draw(self):
 pass
 def print_figure(self, filename, dpi=100,
 facecolor='w', edgecolor='w',
 orientation='portrait'):
 basename, ext = os.path.splitext(filename)
 if not len(ext): filename += '.svg'
 self._svgwriter = StringIO()
 renderer = RendererSVG(self._svgwriter,self.figure.figsize[0]*dpi,self.figure.figsize[1]*dpi)
 print dpi
 print (self.figure.figsize[0]*dpi,
 self.figure.figsize[1]*dpi)
 self._svgwriter.write(_svgProlog % (renderer.width,renderer.height))
 self.figure.draw(renderer)
 renderer.finish()
 try: fh = file(filename, 'w')
 except IOError:
 error_msg_svg('Could not open %s for writing' % filename)
 return
 print >>fh, renderer.get_svg()
class FigureManagerSVG(FigureManagerBase):
 pass
FigureManager = FigureManagerSVG
error_msg = error_msg_svg
_svgProlog = """<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>
<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.0//EN\"
\"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd\">
<!-- Created with matplotlib (http://matplotlib.sourceforge.net/) -->
<svg
 xmlns=\"http://www.w3.org/2000/svg\"
 xmlns:xlink=\"http://www.w3.org/1999/xlink\"
 version=\"1.0\"
 x=\"0.0000000\"
 y=\"0.0000000\"
 width=\"%f\"
 height=\"%f\"
 id=\"svg1\">
"""

Thanks for your reply,
Problem solved!
I am now deleting all '_patches'-data beyond my viewing window's time 
frame which is set to 60 seconds.
I call:
	if len(ax._patches) > (60*10):
	 del ax._patches[:10]
I have noticed that there are 10 entries made to the 'patches'-data for 
every bargraph I add.
Can you explain this - and/or possibly direct me to a page to read up more 
about "_patches".
Thanks for everything
Leon
On 2004年5月25日 10:29:41 -0500, John Hunter 
<jdh...@ac...> wrote:
>>>>>> "Leon" == Leon Brits <leo...@ne...> writes:
>
> Leon> Does this help? Should I tell the axes to "not remember"
> Leon> the out-of-view data?
>
> Yes, this appears to be your problem. Normally, I would adivse you to
> update the data of your bar elements (patches.Rectangle instances).
> This would avoid the overhead of creating all the extra objects. But
> for stacked bar graphs this may be more hassle than it's worth.
>
> But you definitely do need to clear the old instances before adding
> the new ones. There are two ways to do this
>
> ax.cla() # clear all the axes elements
>
> This might introduce flicker in to your graph so you'll have to test
> it. A hack is to simply clear all the patch instances from the axes.
> If you are not using other patch building plot commands (eg hist,
> scatter, bar) this should work fine and be the fastest solution
>
> ax._patches = []
>
> It might be worthwhile to add a more limited clear function to the
> axes. cla clears everything, but in some cases (like this one) you
> might just want clear the lines, or the patches, or the text.
>
> If you are following matplotlib-users, I just did some profiling of
> animated graphs and found that text operations were eating up about
> 50% of the CPU time on animated graphs. The good news is that the
> vast majority of this time can be reclaimed with some fairly easy
> optimizations.
>
> JDH

>>>>> "Leon" == Leon Brits <leo...@ne...> writes:
 Leon> Does this help? Should I tell the axes to "not remember"
 Leon> the out-of-view data?
Yes, this appears to be your problem. Normally, I would adivse you to
update the data of your bar elements (patches.Rectangle instances).
This would avoid the overhead of creating all the extra objects. But
for stacked bar graphs this may be more hassle than it's worth.
But you definitely do need to clear the old instances before adding
the new ones. There are two ways to do this
 ax.cla() # clear all the axes elements
This might introduce flicker in to your graph so you'll have to test
it. A hack is to simply clear all the patch instances from the axes.
If you are not using other patch building plot commands (eg hist,
scatter, bar) this should work fine and be the fastest solution
 ax._patches = []
It might be worthwhile to add a more limited clear function to the
axes. cla clears everything, but in some cases (like this one) you
might just want clear the lines, or the patches, or the text.
If you are following matplotlib-users, I just did some profiling of
animated graphs and found that text operations were eating up about
50% of the CPU time on animated graphs. The good news is that the
vast majority of this time can be reclaimed with some fairly easy
optimizations.
JDH

On 2004年5月25日 08:38:40 -0500, John Hunter 
<jdh...@ac...> wrote:
>>>>>> "Leon" == Leon Brits <leo...@ne...> writes:
>
> Leon> Hi, I experience a slowdown in the command canvas.draw(). I
> Leon> am drawing a moving bargraph by shifting the x-axis and
> Leon> adding a new bar. The new bargraph is added every second,
> Leon> but starts to slows down after 5 minutes.
>
> Leon> I monitored the time it takes to execute the canvas.draw()
> Leon> command and this increases from 200ms to over 1 second
> Leon> within the 5 minutes and therfore the delay since I am
> Leon> trying to display the new bar every second.
>
> Leon> Any help appreciated! Thnaks Leon
>
> Could you post your code, or at least the core of it that does the
> drawing update?
>
> JDH
I cannot give you everything, but here is the main part....
	g_canvas = get_current_fig_manager().canvas
	< SNIP >
	# Build stacked bargraph
	for jin range(data[....])
		# Select axes to add BAR too...
		axes(g_display[j]['axes']['handle'])
	 b = bar(delta_time, h, 1, g_display[j]['offset'], color)
 	g_display[j]['offset'] += h		# build stacked bar
		# setup legend names & colors
 g_display[j]['bars'].append(b)
 g_display[j]['legend'].append(data['legend'])
	< SNIP >
	# Select axes to update...
	axes(g_display[j]['axes']['handle'])
 g_display[j]['maxy'] = Search_YMax(g_display[j]['maxy'], 
g_display[j]['offset'])
 g_display[j]['y-scale'] = Scale_YMax(g_display[j]['maxy'][0])
 g_display[j]['axes']['handle'].set_ylim([0, g_display[j]['y-scale']])
 g_display[j]['axes']['handle'].set_xlim([x_start, x_end])
 legend(g_display[j]['bars'], g_display[j]['legend'], 'lower left')
 ylabel(g_display[j]['unit'], g_font['unit'])
 g_canvas.draw()
Does this help?
Should I tell the axes to "not remember" the out-of-view data?
Thanks for your quick reply!
Cheers
Leon
-- 
==============================
Leon J. Brits
Netronome Systems (Pty) Ltd.
Tel:+27(0)12-6673650
Fax:+27(0)12-6673635

>>>>> "Leon" == Leon Brits <leo...@ne...> writes:
 Leon> Hi, I experience a slowdown in the command canvas.draw(). I
 Leon> am drawing a moving bargraph by shifting the x-axis and
 Leon> adding a new bar. The new bargraph is added every second,
 Leon> but starts to slows down after 5 minutes.
 Leon> I monitored the time it takes to execute the canvas.draw()
 Leon> command and this increases from 200ms to over 1 second
 Leon> within the 5 minutes and therfore the delay since I am
 Leon> trying to display the new bar every second.
 Leon> Any help appreciated! Thnaks Leon
Could you post your code, or at least the core of it that does the
drawing update?
JDH

Hi,
I experience a slowdown in the command canvas.draw().
I am drawing a moving bargraph by shifting the x-axis and adding a new bar.
The new bargraph is added every second, but starts to slows down after 5 
minutes.
I monitored the time it takes to execute the canvas.draw() command and 
this increases from 200ms to over 1 second within the 5 minutes and 
therfore the delay since I am trying to display the new bar every second.
Any help appreciated!
Thnaks
Leon
# Using GTK
tyd = time.time()
g_canvas.draw()
print "canvas time =",time.time()-tyd

Dear Open Source developer
I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.
With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.
With many thanks for your participation,
Benno Luthiger
PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.
_______________________________________________________________________
Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich
Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

I'm having trouble building matplotlib CVS HEAD using Windows XP, and 
Python 2.2.1, Microsoft .NET 2003 Professional cl.exe:
I just checked out numarray CVS Head ('0.9.1', but I'm on the anonymous 
pserver, so there may be a several-day lag), built that, removed the old 
version from C:\Python22, and installed the new verison.
I also have Numeric 21.0 installed from the bdist_wininst installer.
Compiliing matplotlib (fresh from CVS) with either numarray or Numeric 
specified in setup.py, I get: This seems like a (simple?) C++ issue in 
_transforms.cpp. I try to avoid C++ myself, so hopefully this error 
report will be enought for someone else to solve it...
running build_ext
building 'matplotlib._transforms' extension
_transforms.cpp
c:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\cl.exe /c 
/nologo /Ox /MD /W3 /GX -Isrc -I. -IC:\Python22\include 
/Tpsrc/_transforms.cpp 1/Fobuild\temp.win32-2.2\Release\_transforms.obj 
-DNUMARRAY
CXX\Objects.hxx(1128) : error C2039: 'random_access_iterator' : is not a 
member of 'std'
 CXX\Objects.hxx(1128) : see reference to class template 
instantiation 'Py::SeqBase<T>::iterator' being compiled
 CXX\Objects.hxx(1390) : see reference to class template 
instantiation 'Py::SeqBase<T>' being compiled
CXX\Objects.hxx(1128) : error C2504: 'random_access_iterator' : base 
class undefined
CXX\Objects.hxx(1128) : error C2143: syntax error : missing ',' before '<'
CXX\Objects.hxx(1264) : error C2039: 'random_access_iterator' : is not a 
member of 'std'
 CXX\Objects.hxx(1264) : see reference to class template 
instantiation 'Py::SeqBase<T>::const_iterator' being compiled
CXX\Objects.hxx(1264) : error C2504: 'random_access_iterator' : base 
class undefined
CXX\Objects.hxx(1264) : error C2143: syntax error : missing ',' before '<'
CXX\Objects.hxx(1128) : error C2039: 'random_access_iterator' : is not a 
member of 'std'
 CXX\Objects.hxx(2162) : see reference to class template 
instantiation 'Py::SeqBase<T>::iterator' being compiled
 with
 [
 T=Py::Object
 ]
 CXX\Objects.hxx(2149) : see reference to class template 
instantiation 'Py::MapBase<T>::iterator' being compiled
 CXX\Objects.hxx(2330) : see reference to class template 
instantiation 'Py::MapBase<T>' being compiled
CXX\Objects.hxx(1128) : error C2504: 'random_access_iterator' : base 
class undefined
CXX\Objects.hxx(1128) : error C2143: syntax error : missing ',' before '<'
src\_transforms.cpp(110) : error C2039: 'numeric_limits' : is not a 
member of 'std'
src\_transforms.cpp(110) : error C2065: 'numeric_limits' : undeclared 
identifier
src\_transforms.cpp(110) : error C2062: type 'double' unexpected
src\_transforms.cpp(111) : error C2039: 'numeric_limits' : is not a 
member of 'std'
src\_transforms.cpp(111) : error C2062: type 'double' unexpected
src\_transforms.cpp(111) : error C3861: 'numeric_limits': identifier not 
found, even with argument-dependent lookup
src\_transforms.cpp(280) : error C2039: 'numeric_limits' : is not a 
member of 'std'
src\_transforms.cpp(280) : error C2062: type 'double' unexpected
src\_transforms.cpp(281) : error C2039: 'numeric_limits' : is not a 
member of 'std'
src\_transforms.cpp(281) : error C2062: type 'double' unexpected
src\_transforms.cpp(282) : error C2039: 'numeric_limits' : is not a 
member of 'std'
src\_transforms.cpp(282) : error C2062: type 'double' unexpected
src\_transforms.cpp(283) : error C2039: 'numeric_limits' : is not a 
member of 'std'
src\_transforms.cpp(283) : error C2062: type 'double' unexpected
src\_transforms.cpp(280) : error C3861: 'numeric_limits': identifier not 
found, even with argument-dependent lookup
src\_transforms.cpp(281) : error C3861: 'numeric_limits': identifier not 
found, even with argument-dependent lookup
src\_transforms.cpp(282) : error C3861: 'numeric_limits': identifier not 
found, even with argument-dependent lookup
src\_transforms.cpp(283) : error C3861: 'numeric_limits': identifier not 
found, even with argument-dependent lookup
creating build\temp.win32-2.2
creating build\temp.win32-2.2\Release
error: command 'cl.exe' failed with exit status 2

Hi,
Old versions of Numeric (specifically, version 21) don't have symbols 
such at UInt8 defined. I modified nc_imports to deal with this case, 
but I wanted to fly it past the experts in case it misses some subtle 
intricacy.
Furthermore, I get the following bug when trying to run 
examples/simple_plot.py on Windows XP, matplotlib 0.54, Numeric 21. Is 
this fixable?
Traceback (most recent call last):
 File "simple_plot.py", line 16, in ?
 show()
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_wx.py", line 
1124, in show
 figwin.canvas.draw()
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_wxagg.py", 
line 50, in draw
 agg.draw()
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_agg.py", line 
299, in draw
 self.figure.draw(self.renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, 
in draw
 for a in self.axes: a.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw
 self.xaxis.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw
 tick.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 130, in draw
 if self.label1On: self.label1.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\text.py", line 193, in draw
 bbox, info = self._get_layout(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\text.py", line 129, in 
_get_layout
 txs = [float(v[0][0]) for v in cornersRotated]
 File "C:\Python22\Lib\site-packages\Numeric\UserArray.py", line 154, 
in __float__
 def __float__(self): return self._scalarfunc(float)
 File "C:\Python22\Lib\site-packages\Numeric\UserArray.py", line 151, 
in _scalarfunc
 raise TypeError, "only rank-0 arrays can be converted to Python 
scalars."
TypeError: only rank-0 arrays can be converted to Python scalars.

On Mon, 2004年05月17日 at 18:48, John Hunter wrote:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
> 
> Perry> I keep forgetting that unless the clf() is done, that all
> Perry> the previous data elements are still present. And thus the
> Perry> error will repeat. (Waiting for that feature to allow
> Perry> autoclearing in interactive mode I guess)
> 
> I added a hold command and axes.hold property to matplotlibrc. In
> CVS. 
> 
> Next release is due out in a day or two (a couple of small bugs to
> squash). If any of you can test CVS that would be great - there have
> been a lot of changes since 0.53 that touch virtually every part of
> matplotlib (see the CHANGELOG in the sdist). Here is a snapshot if
> you don't have ready CVS access
> http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54c.tar.gz
> - sorry no win32 snapshots at the ready.
> 
> Todd, do you still want to build a numarray version? If so, I'll send
> you an sdist that I use to build my system and you can build for
> numarray and send me back the exe.
Yes. Please send me the sdist.
Todd

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> I keep forgetting that unless the clf() is done, that all
 Perry> the previous data elements are still present. And thus the
 Perry> error will repeat. (Waiting for that feature to allow
 Perry> autoclearing in interactive mode I guess)
I added a hold command and axes.hold property to matplotlibrc. In
CVS. 
Next release is due out in a day or two (a couple of small bugs to
squash). If any of you can test CVS that would be great - there have
been a lot of changes since 0.53 that touch virtually every part of
matplotlib (see the CHANGELOG in the sdist). Here is a snapshot if
you don't have ready CVS access
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54c.tar.gz
- sorry no win32 snapshots at the ready.
Todd, do you still want to build a numarray version? If so, I'll send
you an sdist that I use to build my system and you can build for
numarray and send me back the exe.
JDH

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