[matplotlib-devel] matplotlib and matplotlibrc
Hello, I use matplotlib 0.87.3 on win32 with wxpython. From the command line, the numeric package is set correctly : numpy (read from matplotlibrc) and all woks fine. I try to use matplotlib from pyxpcom (the connector between xpcom and python in the mozilla world), it seems matplotlib doesn't read matplotlibrc since it looks for numeric package which is not installed. I don't undestand, is there a reason the matplotlibrc file is not read, interpreted ? thanks a lot, Cyril. ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] collection efficiency improvement
> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
Eric> Based on a quick look, I think it would be easy to make
Eric> LineCollection and PolyCollection accept a numerix array in
Eric> place of [(x,y), (x,y), ...] for each line segment or
Eric> polygon; specifically, this could replaced by an N x 2
Eric> array, where the first column would be x and the second
Eric> would be y. Backwards compatibility could be maintained
Eric> easily. This would eliminate quite a bit of useless
Eric> conversion back and forth among lists, tuples, and arrays.
Eric> As it is, each sequence of sequences is converted to a pair
Eric> of arrays in backend_bases, and typically it started out as
Eric> either a 2-D numerix array or a pair of 1-D arrays in the
Eric> code that is calling the collection constructor.
I think this is a useful enhancement. I would think that representing
each segment as (x,y) where x and y are 1D arrays, might be slightly
more natural than using an Nx2 but others may disagree.
How often does it come up that we want a homogeneous line collection,
ie a bunch of lines segments with the same properties (color,
linewidth...)? The most expensive part of the agg line collection
renderer is probably the multiple calls to render_scanlines, which is
necessary every time we change the linewidth or color.
If all of the lines in a collection shared the same properties, we
could draw the entire path with a combination of lineto/moveto, and
just stroke and render it once (agg has an upper limit on path length
though, since at some point I added the following to draw_lines
if ((i%1)==0) {
//draw the path in chunks
_render_lines_path(path, gc);
path.remove_all();
path.move_to(thisx, thisy);
}
Ie I render it every 1 points.
Actually, as I type this I realize the case of homogeneous lines (and
polys) can be handled by the backend method "draw_path". One
possibility is for the LineCollection to detect the homogeneous case
len(linewidths)==1 and len(colors)==1 and call out to draw_path
instead of draw_line_collection (the same could be done for a regular
poly collection). Some extra extension code would probably be
necessary to build the path efficiently from numerix arrays, and to
handle the "chunking" problem to avoid extra long paths, but for
certain special cases (scatters and quiver w/o color mapping) it would
probably be a big win. The downside is that not all backend implement
draw_paths, but the Collection front-end could detect this and fall
back on the old approach if draw_paths is not implemented.
JDH
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Questions about mathtext, unicode conversion etc.
> "Edin" == Edin Salkovi§ <[EMAIL PROTECTED]> writes:
Edin> Hi all, Is it that the code in the mathtext module looks
Edin> ugly or is it just me not understanding it? Also, if anyone
Edin> has some good online sources about parsing etc. on the net,
Edin> I vwould realy appreciate it.
It's probably you not understanding it :-) In my opinion, the code is
pretty nice and modular, with a few exceptions, but I'm biased.
Parsers can be a little hard to understand at first. You might start
by trying to understand pyparsing
http://pyparsing.wikispaces.com
and work through some of the basic examples there. Once you have your
head wrapped around that, it will get easier.
Edin> Considering the foowing code (picked on random, from
Edin> mathtext.py)
Edin> I don't understand, for example, what does the statement:
Edin> expression.parseString( s )
Edin> do?
Edin> "expression" is defined globaly, and is called (that is -
Edin> its method) only once in the above definition of the
Edin> function, but I don't understand - what does that particular
Edin> line do?!?
It's not defined globally, but at module level. There is only one
expression that represents a TeX math expression (at least as far as
mathtext is concerned) so it is right that there is only one of them
at module level. It's like saying "a name is a first name followed by
an optional middle initial followed by a last name". You only need to
define this one, and then you set handlers to handle the different
components.
The expression assigns subexpressions to handlers. The statement
below says that an expression is one or more of a space, font element,
an accent, a symbol, a subscript, etc...
expression = OneOrMore(
space ^ font ^ accent ^ symbol ^ subscript ^ superscript ^ subsuperscript ^
group ^ composite ).setParseAction(handler.expression).setName("expression")
A subscript, for example, is a symbol group followed by an underscore
followed by a symbol group
subscript << Group( Optional(symgroup) + Literal('_') + symgroup )
and the handler is defined as
subscript = Forward().setParseAction(handler.subscript).setName("subscript")
which means that the function handler.subscript will be called every
time the pattern is matched. The tokens will be the first symbol
group, the underscore, and the second symbol group. Here is the
implementation of that function
def subscript(self, s, loc, toks):
assert(len(toks)==1)
#print 'subsup', toks
if len(toks[0])==2:
under, next = toks[0]
prev = SpaceElement(0)
else:
prev, under, next = toks[0]
if self.is_overunder(prev):
prev.neighbors['below'] = next
else:
prev.neighbors['subscript'] = next
return loc, [prev]
This grabs the tokens and assigns them to the names "prev" and "next".
Every element in the TeX expression is a special case of an Element,
and every Element has a dictionary mapping surrounding elements to
relative locations, either above or below or right or superscript or
subscript. The rest of this function takes the "next" element, and
assigns it either below (eg for \Sum_\0) or subscript (eg for x_0) and
the layout engine will then take this big tree and lay it out. See
for example the "set_origin" function?
Edin> -- Regarding the unicode s
upport in mathtext, mathtext
Edin> currently uses the folowing dictionary for getting the glyph
Edin> info out of the font files:
Edin> latex_to_bakoma = {
Edin> r'\oint' : ('cmex10', 45), r'\bigodot' : ('cmex10', 50),
Edin> r'\bigoplus' : ('cmex10', 55), r'\bigotimes' : ('cmex10',
Edin> 59), r'\sum' : ('cmex10', 51), r'\prod' : ('cmex10', 24),
Edin> ...
Edin> }
Edin> I managed to build the following dictionary(little more left
Edin> to be done): tex_to_unicode = { r'\S' : u'\u00a7', r'\P' :
Edin> u'\u00b6', r'\Gamma' : u'\u0393', r'\Delta' : u'\u0394',
Edin> r'\Theta' : u'\u0398', r'\Lambda' : u'\u039b', r'\Xi' :
Edin> u'\u039e', r'\Pi' : u'\u03a0', r'\Sigma' : u'\u03a3',
Edin> unicode_to_tex is straight forward. Am I on the right
Edin> track? What should I do next?
Yes, this looks like the right approach. Once you have this
dictionary mostly working, you will need to try and make it work with
a set of unicode fonts. So instead of having the tex symbol point to
a file name and glyph index, you will need to parse a set of unicode
fonts to see which unicode symbols they provide and build a mapping
from unicode name -> file, glyph index. Then when you encounter a tex
symbol, you can use your tex_to_unicode dict combined with your
unicode -> filename, glyphindex dict to get the desired glyph.
Edin> I also noticed that some TeX commands (commands in the sense
Edin> that they can have arguments enclosed in brackets {}) are
Edin> defined as only symbols: \sqrt alo
[matplotlib-devel] Questions about mathtext, unicode conversion etc.
Hi all,
Is it that the code in the mathtext module looks ugly or is it just me
not understanding it?
Also, if anyone has some good online sources about parsing etc. on the
net, I vwould realy appreciate it.
Considering the folowing code (picked on random, from mathtext.py)
===
def math_parse_s_ft2font(s, dpi, fontsize, angle=0):
"""
Parse the math expression s, return the (bbox, fonts) tuple needed
to render it.
fontsize must be in points
return is width, height, fonts
"""
major, minor1, minor2, tmp, tmp = sys.version_info
if major==2 and minor1==2:
raise SystemExit('mathtext broken on python2.2. We hope to
get this fixed soon')
cacheKey = (s, dpi, fontsize, angle)
s = s[1:-1] # strip the $ from front and back
if math_parse_s_ft2font.cache.has_key(cacheKey):
w, h, bfonts = math_parse_s_ft2font.cache[cacheKey]
return w, h, bfonts.fonts.values()
bakomaFonts = BakomaTrueTypeFonts()
Element.fonts = bakomaFonts
handler.clear()
expression.parseString( s )
handler.expr.set_size_info(fontsize, dpi)
# set the origin once to allow w, h compution
handler.expr.set_origin(0, 0)
xmin = min([e.xmin() for e in handler.symbols])
xmax = max([e.xmax() for e in handler.symbols])
ymin = min([e.ymin() for e in handler.symbols])
ymax = max([e.ymax() for e in handler.symbols])
# now set the true origin - doesn't affect with and height
w, h = xmax-xmin, ymax-ymin
# a small pad for the canvas size
w += 2
h += 2
handler.expr.set_origin(0, h-ymax)
Element.fonts.set_canvas_size(w,h)
handler.expr.render()
handler.clear()
math_parse_s_ft2font.cache[cacheKey] = w, h, bakomaFonts
return w, h, bakomaFonts.fonts.values()
math_parse_s_ft2font.cache = {}
I don't understand, for example, what does the statement:
expression.parseString( s )
do?
"expression" is defined globaly, and is called (that is - its method)
only once in the above definition of the function, but I don't
understand - what does that particular line do?!?
--
Regarding the unicode support in mathtext, mathtext currently uses the
folowing dictionary for getting the glyph info out of the font files:
latex_to_bakoma = {
r'\oint': ('cmex10', 45),
r'\bigodot' : ('cmex10', 50),
r'\bigoplus': ('cmex10', 55),
r'\bigotimes' : ('cmex10', 59),
r'\sum' : ('cmex10', 51),
r'\prod': ('cmex10', 24),
...
}
I managed to build the following dictionary(little more left to be done):
tex_to_unicode = {
r'\S' : u'\u00a7',
r'\P' : u'\u00b6',
r'\Gamma' : u'\u0393',
r'\Delta' : u'\u0394',
r'\Theta' : u'\u0398',
r'\Lambda' : u'\u039b',
r'\Xi' : u'\u039e',
r'\Pi' : u'\u03a0',
r'\Sigma' : u'\u03a3',
r'\Upsilon' : u'\u03a5',
r'\Phi' : u'\u03a6',
r'\Psi' : u'\u03a8',
r'\Omega' : u'\u03a9',
r'\alpha' : u'\u03b1',
r'\beta' : u'\u03b2',
r'\gamma' : u'\u03b3',
r'\delta' : u'\u03b4',
r'\varepsilon' : u'\u03b5',
r'\zeta' : u'\u03b6',
r'\eta' : u'\u03b7',
r'\vartheta' : u'\u03b8',
r'\iota' : u'\u03b9',
r'\kappa' : u'\u03ba',
r'\lambda' : u'\u03bb',
r'\mu' : u'\u03bc',
r'\nu' : u'\u03bd',
r'\xi' : u'\u03be',
r'\pi' : u'\u03c0',
r'\varrho' : u'\u03c1',
r'\varsigma' : u'\u03c2',
r'\sigma' : u'\u03c3',
r'\tau' : u'\u03c4',
r'\upsilon' : u'\u03c5',
r'\varphi' : u'\u03c6',
r'\chi' : u'\u03c7',
r'\psi' : u'\u03c8',
r'\omega' : u'\u03c9',
r'\ell' : u'\u2113',
r'\wp' : u'\u2118',
r'\Omega' : u'\u2126',
r'\Re' : u'\u211c',
r'\Im' : u'\u2111',
r'\aleph' : u'\u05d0',
r'\aleph' : u'\u2135',
r'\spadesuit' : u'\u2660',
r'\heartsuit' : u'\u2661',
r'\diamondsuit' : u'\u2662',
r'\clubsuit' : u'\u2663',
r'\flat' : u'\u266d',
r'\natural' : u'\u266e',
r'\sharp' : u'\u266f',
r'\leftarrow' : u'\u2190',
r'\uparrow' : u'\u2191',
r'\rightarrow' : u'\u2192',
r'\downarrow' : u'\u2193',
r'\Rightarrow' : u'\u21d2',
r'\Leftrightarrow' : u'\u21d4',
r'\leftrightarrow' : u'\u2194',
r'\updownarrow' : u'\u2195',
r'\forall' : u'\u2200',
r'\exists' : u'\u2203',
r'\emptyset' : u'\u2205',
r'\Delta' : u'\u2206',
r'\nabla' : u'\u2207',
r'\in' : u'\u2208',
r'\ni' : u'\u220b',
r'\prod' : u'\u220f',
r'\coprod' : u'\u2210',
r'\sum' : u'\u2211',
r'-' : u'\u2212',
r'\mp' : u'\u2213',
r'/' : u'\u2215',
r'\ast' : u'\u2217',
r'\circ' : u'\u2218',
r'\bullet' : u'\u2219',
r'\propto' : u'\u221d',
r'\infty' : u'\u221e',
r'\mid' : u'\u2223',
r'\wedge' : u'\u2227',
r'\vee' : u'\u2228',
r'\cap' : u'\u2229',
r'\cup' : u'\u222a',
r'\int' : u'\u222b',
r'\oint' : u'\u222e',
r':' : u'\u2236',
r'\sim' : u'\u223c',
r'\wr' : u'\u2240',
r'\simeq' : u'\u2243',
r'\approx' : u'\u2248',
r'\asymp' : u'\u224d',
r'\equiv' : u'\u2261',
r'\leq' : u'\u2264',
r'\geq' : u'\u2265',
r'\ll' : u'\u226a',
r'\gg' : u'\u226b',
r'\prec' : u'\u227a',
r'\succ' : u'\u227b',
r'\subset' : u'\u2282',
r'\supset' : u'\u2283',
r'\subseteq' : u'\u2286',
r'\supseteq' : u'\u2287',
r'\uplus' : u'\u228e',
r'\sqsubse
Re: [matplotlib-devel] collection efficiency improvement
On 6/15/06, John Hunter <[EMAIL PROTECTED]> wrote: > How often does it come up that we want a homogeneous line collection, > ie a bunch of lines segments with the same properties (color, > linewidth...)? Hi, for b&w PS publication quality plotting, this must be a common thing to draw; contour lines, vectors, xy plots, the axes, tick marks, even fonts can all be constructed from disjoint line segments, no? if matplotlib could pass numerix arrays more or less directly to gtk it could perhaps also become the speed king of plotting packages :) Helge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
