Re: [matplotlib-devel] Plot with no labels
On Fri, Jul 20, 2007 at 02:55:26PM -0500, John Hunter wrote:
> >From the legend docstring:
> USAGE:
> Make a legend with existing lines
> >>> legend()
> legend by itself will try and build a legend using the label
> property of the lines/patches/collections. You can set the label of
> a line by doing plot(x, y, label='my data') or line.set_label('my
> data'). If label is set to '_nolegend_', the item will not be shown
> in legend.
Damn it. I feel so stupid. I looked at that docstring so often, but never
noticed this. It is right in the middle of the docstring.
Thanks for pointing this out to me, I've been doing all sorts of
complicated things to do this, so far.
Gaël
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Fri, Jul 20, 2007 at 03:25:06PM -0600, Fernando Perez wrote: > The point is that instead of > -from mplconfig import MPLConfig, ConfigManager, mkConfigObj > I prefer: > +from tconfig import ConfigManager, mkConfigObj > +from mplconfig import MPLConfig > since ConfigManager and mkConfigObj really live in tconfig, I'm not > tying my top-level code to an implementation detail of an intermediate > module (what it imports and how it names it). I mention this > explicitly just because I think it's a good bit of coding practice. That really depends whether you what mplconfig to be able to provide its own abstract layer over tconfig, with possibly modified ConfigManager and mkConfigObj (remember EZvisage). I don't think it is the case here, but I kust wanted to point out that I am not sure this is allways good coding practice. My 2 euro cents, Gaël - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Steeling some of you colormaps
On Tue, Jul 17, 2007 at 08:17:50PM -0500, John Hunter wrote: > On 7/17/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > > I have written a small script that uses pylab to retrieve the data for > > the MPL colormaps. I am thinking of checking in both the script, and the > > resulting data in Mayavi2 (FBSD licenced). Can I do such a thing > > (stealing colormaps ?). > You are welcome to do this, but you might be better served stealing > our colormapping infrastructure and data directly (_cm.py, cm.py and > colors.py) rather than trying to extract it via pylab. Well, we have to convert them anyhow, so I thought I might as well do the convertion while stealing them. > Some of our colormap data is borrowed from other sources (colorbrewer, > yorick). They have BSD compatible licenses, but have some > restrictions that you distribute their licenses. matplotlib does so > in the licenses subdir of the svn repo. Search _cm.py for "license" > for more details. Great, I did that. Cheers, Gaël - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On Fri, Jul 20, 2007 at 05:05:40PM -0700, Christopher Barker wrote: > >> so I think it does make sense to bring the common names that show up in > >> math expressions into the main namespace. > > >> This is probably best just done by each individual according to his/her > >> taste. > > > > That's what I'm trying to get away from. I want to be able to write > > the contains() function in patch.py and just use the normal math where > > it makes sense to use normal math. > > Ahh -- we're back on an a mpl-devel topic now. > > I was thinking that you were proposing a "math" namespace for pylab > users -- but it sounds like you're proposing a standard set of math > names that will be brought in to modules for the matplotlib project > itself. Different issue. Through the use of "from mpl.math import *" yes. > I don't write enough MPL internal code to have any opinion on that. I'll let the code speak for itself: ~/src/matplotlib/lib/matplotlib pkienzle$ for sym in $symlist; do > echo `grep "[^A-Za-z0-9_]$sym[^A-Za-z0-9_]" *.py | wc -l` $sym; > done | sort -n -r | column -c 75 163 max 7 remainder 1 cosh 0 isnormal 136 arg 7 pow 1 arctanh 0 isinf 109 min 7 inf 1 arcsinh 0 isfinite 102 log 6 arctan2 1 arccosh 0 frexp 64 pi 5 fabs 0 trunc 0 fmin 56 sqrt 4 imag 0 tgamma0 fmax 44 abs 3 tan 0 signbit 0 fdim 38 sin 3 nan 0 scalbn0 expm1 28 cos 3 log2 0 rint 0 exp2 23 minimum 3 hypot 0 remquo0 erfc 22 round2 isnan 0 nexttoward0 erf 19 maximum 2 arctan0 nearbyingt0 cproj 19 floor2 arcsin0 modf 0 copysign 18 log102 arccos0 logb 0 conj 18 ceil 1 tanh 0 log1p 0 cbrt 13 real 1 sinh 0 lgamma0 NaN 12 exp 1 fmod 0 ldexp 0 Inf I used the following list: symlist=`cat
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote: > I used the following list: > > symlist=`cat < pi inf Inf nan NaN > isfinite isnormal isnan isinf > arccos arcsin arctan arctan2 cos sin tan > arccosh arcsinh arctanh cosh sinh tanh > exp log log10 expm1 log1p exp2 log2 > pow sqrt cbrt erf erfc lgamma tgamma hypot > fmod remainder remquo > fabs fdim fmax fmin > copysign signbit frexp ldexp logb modf scalbn > ceil floor rint nexttoward nearbyingt round trunc > conj cproj abs arg imag real > min max minimum maximum > EOF` > > This measure doesn't distinguish between comments and > code, but it should still be good enough for the purposes As far as namespaecs are concerned, I agree they are a good idea and should be used in almost all places. I also don't want the perfect to be the enemy of the good, or succumb to a foolish consistency, so I think is is OK to have some very common names that have a clear meaning to be used w/o a namespace. I have been following your discussion at a bit of a distance: are you talking about using scalar functions or array functions here, eg math.sqrt vs numpy.sqrt? Also, a few of your symbols clash with python builtins (min, max, abs) which is best avoided. Finally, how would you feel about allowing these symbols in the module namespace, but w/o the import * semantics, eg, for these symbols we do from mpl.math import exp, sin, pi, sin, cos, ... it does defeat the purpose of your idea a bit, which is to have a set of commonly agreed on math symbols that everyone agrees on and we can always rely on with easy convenience. On the other hand, I am more comfortable being explicit here. If I am missing some fundamental ideas, please forgive me and enlighten me, because as I say I've been following this (previous) thread only loosely. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plot with no labels
On 7/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > Damn it. I feel so stupid. I looked at that docstring so often, but never > noticed this. It is right in the middle of the docstring. Have you read "The Purloined Letter" by Edgar Allen Poe? The basic story is that a man is in possession of a letter that the government or some other organization badly wants their hands on. He is afraid to carry it because he knows he will be mugged for it, he is afraid to leave it in his house because he knows it will be ransacked. Eventually, he cleverly decides to leave it on his coffee table. When he comes home, his house has been totally ransacked, couch cushions pulled apart, etc. The letter remains on the table untouched, as the intruders didn't consider to look for it in such an obvious place. Yesterday, Chris wrote me offlist expressing his mild embarrassment for asking where the agg module could be found, after failing to find it on google. It didn't occur to him to check the mpl src code, assuming it was a 3rd party module. So don't feel stupid -- it happens to everyone. Or perhaps we're all stupid. Well, everyone but Robert. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On Sat, Jul 21, 2007 at 09:42:16AM -0500, John Hunter wrote: > On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote: > > I used the following list: > > > > symlist=`cat < > pi inf Inf nan NaN > > isfinite isnormal isnan isinf > > arccos arcsin arctan arctan2 cos sin tan > > arccosh arcsinh arctanh cosh sinh tanh > > exp log log10 expm1 log1p exp2 log2 > > pow sqrt cbrt erf erfc lgamma tgamma hypot > > fmod remainder remquo > > fabs fdim fmax fmin > > copysign signbit frexp ldexp logb modf scalbn > > ceil floor rint nexttoward nearbyingt round trunc > > conj cproj abs arg imag real > > min max minimum maximum > > EOF` > > > > This measure doesn't distinguish between comments and > > code, but it should still be good enough for the purposes > > As far as namespaecs are concerned, I agree they are a good idea and > should be used in almost all places. I also don't want the perfect to > be the enemy of the good, or succumb to a foolish consistency, so I > think is is OK to have some very common names that have a clear > meaning to be used w/o a namespace. I have been following your > discussion at a bit of a distance: are you talking about using scalar > functions or array functions here, eg math.sqrt vs numpy.sqrt? Also, Since numpy.* handles scalars but math.* doesn't handle vectors, I suggest importing from numpy. > a few of your symbols clash with python builtins (min, max, abs) which > is best avoided. Feel free to tune the list appropriately. Particularly since max/min/abs already do the right things with vectors: >>> import numpy >>> a = numpy.array([1,2,3,4]) >>> b = numpy.array([4,3,-2,-1]) >>> abs(b) array([4, 3, 2, 1]) >>> isinstance(abs(b),numpy.ndarray) True >>> min(a) 1 >>> min(b) -2 Well, mostly 8-) >>> min(a,b) Traceback (most recent call last): File "", line 1, in ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() > Finally, how would you feel about allowing these > symbols in the module namespace, but w/o the import * semantics, eg, > for these symbols we do > > from mpl.math import exp, sin, pi, sin, cos, ... > > it does defeat the purpose of your idea a bit, which is to have a set > of commonly agreed on math symbols that everyone agrees on and we can > always rely on with easy convenience. On the other hand, I am more > comfortable being explicit here. That's acceptable. If the list of common items were shorter it would be easier. Now whenever I use an expression I have to search the file for the math import statement and check whether the particular symbol I need has already been added to the list. For my own projects I started making a standard import line I could cut and paste into every file, but it came to more than 80 characters. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On Sat, Jul 21, 2007 at 11:34:07AM -0400, Paul Kienzle wrote: > Feel free to tune the list appropriately. Particularly since max/min/abs > already do the right things with vectors: Hell, not with anything that more than 1D ! Beware. Gaël - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] sample canvas object code
Hi,
I'm attaching the canvas object code I've been playing with.
The API is still incomplete, but in the spirit of release early,
release often, I'll put it out there for people to comment on.
This should use a common callback mechanism with mpl (e.g., the
user should bind to a axis limit change event in much the same
way that they bind to mouse events on an artist), but for the
purposes of putting together a demo I created a small one of
my own. Maybe someone with Traits knowledge can show me how
much better it could be?
- Paul
"""
Extension to MPL to support the binding of artists to key/mouse events.
"""
class Selection:
"""
Store and compare selections.
"""
# TODO: We need some way to check in prop matches, preferably
# TODO: without imposing structure on prop.
artist=None
prop={}
def __init__(self,artist=None,prop={}):
self.artist,self.prop = artist,self.prop
def __eq__(self,other):
return self.artist is other.artist
def __ne__(self,other):
return self.artist is not other.artist
def __nonzero__(self):
return self.artist is not None
class BindArtist:
# Track keyboard modifiers for events.
# TODO: Move keyboard modifier support into the backend. We cannot
# TODO: properly support it from outside the windowing system since there
# TODO: is no way to recognized whether shift is held down when the mouse
# TODO: first clicks on the the application window.
control,shift,alt,meta=False,False,False,False
# Track doubleclick
dclick_threshhold = 0.25
_last_button, _last_time = None, 0
# Mouse/keyboard events we can bind to
events= ['enter','leave','motion','click','dclick','drag','release',
'scroll','key','keyup']
# TODO: Need our own event structure
def __init__(self,figure):
canvas = figure.canvas
# Link to keyboard/mouse
self._connections = [
canvas.mpl_connect('motion_notify_event',self._onMotion),
canvas.mpl_connect('button_press_event',self._onClick),
canvas.mpl_connect('button_release_event',self._onRelease),
canvas.mpl_connect('key_press_event',self._onKey),
canvas.mpl_connect('key_release_event',self._onKeyRelease),
canvas.mpl_connect('scroll_event',self._onScroll)
]
# Turn off picker if it hasn't already been done
try:
canvas.mpl_disconnect(canvas.button_pick_id)
canvas.mpl_disconnect(canvas.scroll_pick_id)
except:
pass
self.canvas = canvas
self.figure = figure
self.clearall()
def clear(self, *artists):
"""
self.clear(h1,h2,...)
Remove connections for artists h1, h2, ...
Use clearall() to reset all connections.
"""
for h in artists:
for a in self.events:
if h in self._actions[a]: del self._actions[a][h]
if h in self._artists: self._artists.remove(h)
if self._current.artist in artists: self._current = Selection()
if self._hasclick.artist in artists: self._hasclick = Selection()
if self._haskey.artist in artists: self._haskey = Selection()
def clearall(self):
"""
Clear connections to all artists.
Use clear(h1,h2,...) to reset specific artists.
"""
# Don't monitor any actions
self._actions = {}
for action in self.events:
self._actions[action] = {}
# Need activity state
self._artists = []
self._current = Selection()
self._hasclick = Selection()
self._haskey = Selection()
def disconnect(self):
"""
In case we need to disconnect from the canvas...
"""
for cid in self._connections: canvas.mpl_disconnect(cid)
self._connections = []
def __del__(self):
self.disconnect()
def __call__(self,trigger,artist,action):
"""Register a callback for an artist to a particular trigger event.
usage:
self.connect(eventname,artist,action)
where:
eventname is a string
artist is the particular graph object to respond to the event
action(event,**kw) is called when the event is triggered
The action callback is associated with particular artists.
Different artists will have different kwargs. See documentation
on the contains() method for each artist. One common properties
are ind for the index of the item under the cursor, which is
returned by Line2D and by collections.
The following events are supported:
enter: mouse cursor moves into the artist or to a new index
leave: mouse cursor leaves the artist
click: mouse button pressed on the artist
drag:
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
John Hunter wrote: [...] > functions or array functions here, eg math.sqrt vs numpy.sqrt? Also, > a few of your symbols clash with python builtins (min, max, abs) which > is best avoided. Finally, how would you feel about allowing these > symbols in the module namespace, but w/o the import * semantics, eg, > for these symbols we do > > from mpl.math import exp, sin, pi, sin, cos, ... There is no point in this; better to import these directly from numpy, if that is what is wanted. But sometimes we actually want a masked array version. For many of these things there are up to 5 different possible sources: (builtin, if not math or cmath) math cmath numpy numpy.ma maskedarray Sometimes functions from the different sources do the same thing, but usually at different speeds, and sometimes they don't do the same thing at all. In most cases we want, or at least can manage with, either the numpy version or one of the masked versions, presently accessed via numpy.numerix.npyma, which is imported via import numpy.numerix.npyma as ma The recently introduced policy of simply being very explicit *does* work; when looking at an expression one always knows which functions are being invoked. Like Paul, I recoil a bit at the clunky appearance, but apparently unlike Paul, I find the explicitness helpful--especially since I am very conscious of the need to use masked versions in some places. There is nothing inherently wrong with being explicit by importing some symbols into the module namespace with lines at the top, but this works best if there are not too many of those symbols, if they don't clash with symbols from other modules one is using, and if the module is not too long. A prime example of a case where these conditions are violated is axes.py. Consider two possible policies: Common to both: c1) Never mask a builtin. c2) Use nonconflicting names, specifically, always use amin and amax from numpy or ma instead of min or max. c3) Use methods in preference to functions where possible; this has the advantage of taking care of masked or ordinary cases automatically. 1) Present: always be explicit: npy.sin or ma.sin or math.sin or cmath.sin. (For scalars, the math module functions are much faster than the numpy versions, but on the other hand they should be called seldom enough that this would never matter.) 2) Pick a set of math symbols that may be imported directly from numpy at the top, and either import all routinely, or import as needed. Use explicit "ma." when masked versions are needed. (Depending on design decisions, this could end up being much of the time.) Suboptions: 2a) Include other very common symbols such as array, asarray, newaxis, ones, zeros. 2b) Use something like "from matplotlib.numpyapi import *" to accomplish all of this. This has the advantage of consolidating the names in one place, so one can easily see what the standard names are, and one doesn't have to keep checking the top of the file to see whether an additional name needs to be added. I can accept either of these, so long as we can decide and then get on with life. John, Norbert, and I have already spent time converting some modules to option 1. There was some discussion of this a couple months ago when John first proposed it. Now we have some experience. Another conversion is OK, but let's get it straight and make it the last one. Or leave it. My impression is that other projects typically use something closer to option 2. Prior to our partial conversion to option 1, the tops of our modules were an ugly mess. Option 1 represented a substantial cleanup and clarification--but with the penalty of uglier math expressions. I'm sorry I don't have a strong recommendation yet; I hope the above overly-long text helps the decision process nevertheless. Looking at the options without consideration of prior decisions and work done, my present preference is *mildly* towards option 2 with both suboptions. The biggest problem is the slippery slope--this can easily end up with more and more symbols being added until one is effectively doing "from numpy import *", and I don't want to do that. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote: > True > >>> min(a) > 1 > >>> min(b) We should prefer the numpyisms anyway, a.max(), a.min(), a.absolute(). > > Finally, how would you feel about allowing these > > symbols in the module namespace, but w/o the import * semantics, eg, > > for these symbols we do > > > > from mpl.math import exp, sin, pi, sin, cos, ... > > > > it does defeat the purpose of your idea a bit, which is to have a set > > of commonly agreed on math symbols that everyone agrees on and we can > > always rely on with easy convenience. On the other hand, I am more > > comfortable being explicit here. > > That's acceptable. > > If the list of common items were shorter it would be easier. Now > whenever I use an expression I have to search the file for the math > import statement and check whether the particular symbol I need has > already been added to the list. For my own projects I started making > a standard import line I could cut and paste into every file, but it > came to more than 80 characters. I have no problem with multi-line imports, but Eric hates them. Apparently future python versions will support parentheses in imports to solve the multiline problem, I'm starting to come to the conclusion that the only reason to go with a module with a core set of math/numpy names is if we want to use the import * semantics, right? Otherwise, we might as well do from numpy import the, core, list, of, math, symbols rather than from matplotlib.math import the, core, list, of, math, symbols which only confuses the reader (are these symbols from numpy, math or internal to mpl?) So if we don't want to do that every time, and do want the convenience of having a core set of names available in pretty much every mpl module, we may have well have a "corenamespace" module that utilizes __all__ . Basically, we would be making a statement that we are flying w/o a net here but we know what we are doing. This would be documented in the CODING_GUIDE in the import section. The reason I bring up the idea of a core namespace is there are other functions that belong there along side asarray and pi (iterable and is_string_like come to mind). I'm not advocating this approach -- I'm just pointing out that I see no reason to have a separate module of numpy names if we are going to be explicit about the imports from there. In that case, we may as well explicitly import from numpy. JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On 7/21/07, Eric Firing <[EMAIL PROTECTED]> wrote: > Sometimes functions from the different sources do the same thing, but > usually at different speeds. And the difference may be *very* significant: In [1]: import numpy as N In [2]: import math as M In [3]: nsqrt = N.sqrt In [4]: msqrt = M.sqrt In [5]: def sqtest(sqrt,reps): ...: x = 99.9 ...: for i in xrange(reps): ...: a = sqrt(x) ...: In [13]: reps = int(1e6) In [14]: time sqtest(msqrt,reps) CPU times: user 0.90 s, sys: 0.00 s, total: 0.90 s Wall time: 0.90 In [15]: time sqtest(nsqrt,reps) CPU times: user 7.62 s, sys: 0.39 s, total: 8.02 s Wall time: 8.08 The overhead from numpy for scalars is not trivial at all. And as you pointed out, the semantical differences between math, cmath and numpy (ignoring ma for now) are important enough that people should know exactly what they are getting. I guess if you want to provide a 'common math functions' module with clearly defined conventions for everyday usage, you could do something like (using cos as an example, apply to all names that are common to all such modules): numpy.cos -> cos # unmodified, numpy is the 'default' a la matlab math.cos -> scos # names from math are s-prefixed for 'scalar' (could be 'm') cmath.cos -> ccos # complex names numpy.ma.cos -> macos # masked array names Just an idea... Cheers, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Friday 20 July 2007 5:13:12 pm Fernando Perez wrote: > On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > > This should give you a very reasonable solution for what you wanted to > > > do. > > > > Great! I'm surprised that this was possible. > > And actually easy, for once. > > > Im attaching a patch for the ipython1 sandbox, which adds configobj.py, > > moves the ipython and mpl config code into their own .py files, and moves > > the test code into mpltest.py and ipythontest.py. > > Great, thanks! Committed as r2526. Later we'll move configobj.py > into ipython/externals, but for now it's OK to have it in, so it's > nicely self-contained for people to test this while we settle on > something long-term. > > I've moved the lot into a subdirectory now, so that we can have more > than one set of toys in our sandbox, so update to 2527 and you'll have > tconfig as a self-contained project we can play with until happiness > arrives. I'm working on converting our existing rc code to tconfig this weekend. So far so good. I just wanted to let people know to avoid duplicating effort. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote: > I'm working on converting our existing rc code to tconfig this weekend. So far > so good. I just wanted to let people know to avoid duplicating effort. Excellent! Ping me if you have any problems. I'm going to try and finish hierarchical inclusion of files (aka ipython profiles) now. Consider for example a paper that requires black and white only styles. You could then have in that paper's directory a .matplotlib.conf file with: # paper-specific tweaks include = "$HOME/.matplotlib/matplotlib.conf" [lines] color = 'black' thickness = 2 etc. Or in your .matplotlib dir, you could keep multiple configurations that branch off the basic one for different needs, while keeping common defaults in one central location. In my first implementation I'll have to give up on safe roundtripping to files with recursion active, because it's a bit tricky to do both (not impossible). Cheers, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
John Hunter wrote: > We should prefer the numpyisms anyway, a.max(), a.min(), a.absolute(). Exactly -- OO semantics make the whole namespace thing much more workable. To sum up a bit -- This all started with a comment about how some of the pylab names clash with numpy names, so that: from pylab import * from numpy import * doesn't quite work. I waded in with my usual obsessive advocacy for namespaces, and then it was pointed out that in math expressions, all those name space prefixes made things look pretty ugly. I conceded that is the case, and that in the interests of "practicality beats purity", that maybe having a standard set of math symbols in a module to be import *'ed in could be a good idea. Now to my personal advocacy about this idea: I think that convenience overriding the clarity of namespaces ONLY applies to math expressions, like the example given: > res = sqrt(2*sin(pi*x**2) + cos(x**2) - exp(2*pi*1j)) really is easier to deal with than: > res = npy.sqrt(2*npy.sin(npy.pi*x**2) + npy.cos(x**2) - > npy.exp(2*npy.pi*1j)) But it's not about saving typing -- it's about having math look like math. So the measure of whether a given name should be in the "math" namespace should be whether it's a "math" function, vs. a programming function. Now some data: Paul Kienzle wrote: > I'll let the code speak for itself: > > ~/src/matplotlib/lib/matplotlib pkienzle$ for sym in $symlist; do >> echo `grep "[^A-Za-z0-9_]$sym[^A-Za-z0-9_]" *.py | wc -l` $sym; >> done | sort -n -r | column -c 75 > 163 max 7 remainder 1 cosh 0 isnormal > 136 arg 7 pow 1 arctanh 0 isinf > 109 min 7 inf 1 arcsinh 0 isfinite > 102 log 6 arctan2 1 arccosh 0 frexp > 64 pi 5 fabs 0 trunc 0 fmin > 56 sqrt 4 imag 0 tgamma0 fmax > 44 abs 3 tan 0 signbit 0 fdim > 38 sin 3 nan 0 scalbn0 expm1 > 28 cos 3 log2 0 rint 0 exp2 > 23 minimum 3 hypot 0 remquo0 erfc > 22 round2 isnan 0 nexttoward0 erf > 19 maximum 2 arctan0 nearbyingt0 cproj > 19 floor2 arcsin0 modf 0 copysign > 18 log102 arccos0 logb 0 conj > 18 ceil 1 tanh 0 log1p 0 cbrt > 13 real 1 sinh 0 lgamma0 NaN > 12 exp 1 fmod 0 ldexp 0 Inf Now we're looking at the same data -- but what conclusions do we draw? I think the top three: max, arg, min, don't pass the test of being "math functions", so we have log, pi, sqrt, abs, sin, cos ... that see quite a bit of use, so, may it's worth it, but in all of the MPL code, even 102 uses isn't that much -- and how many of those are buried in larger expressions? i.e.: val = log(x) isn't really that much better than: val = npx.log(x) It only really pays off in something contrived like: z = sin(log(x) * exp(y) + log(n))**(1/log(t)) Now consider: Eric Firing wrote: > For many of these things there are up to 5 different possible sources: > > (builtin, if not math or cmath) > math > cmath > numpy > numpy.ma > maskedarray I'd argue that for MPL, math and cmath are rarely needed, and we hope that soon there will only be one of numpy.ma and maskedarray, but nevertheless, it is an issue. So my conclusion is that's it's not worth it, but reasonable people may disagree, of course! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace [was: Polygon examples broken]
On Sat, Jul 21, 2007 at 08:51:19AM -1000, Eric Firing wrote: > John Hunter wrote: > [...] > > functions or array functions here, eg math.sqrt vs numpy.sqrt? Also, > > a few of your symbols clash with python builtins (min, max, abs) which > > is best avoided. Finally, how would you feel about allowing these > > symbols in the module namespace, but w/o the import * semantics, eg, > > for these symbols we do > > > > from mpl.math import exp, sin, pi, sin, cos, ... > > There is no point in this; better to import these directly from numpy, > if that is what is wanted. oops... missed that detail. Yes of course in we are explicitly importing a name be explicit about where it is coming from. > But sometimes we actually want a masked > array version. > > For many of these things there are up to 5 different possible sources: > > (builtin, if not math or cmath) > math > cmath > numpy > numpy.ma > maskedarray > > Sometimes functions from the different sources do the same thing, but > usually at different speeds, and sometimes they don't do the same thing > at all. In most cases we want, or at least can manage with, either the > numpy version or one of the masked versions, presently accessed via > numpy.numerix.npyma, which is imported via > > import numpy.numerix.npyma as ma > > The recently introduced policy of simply being very explicit *does* > work; when looking at an expression one always knows which functions > are being invoked. Like Paul, I recoil a bit at the clunky appearance, > but apparently unlike Paul, I find the explicitness helpful--especially > since I am very conscious of the need to use masked versions in some places. I'm surprised by the poor performance of numpy scalars reported elsewhere. Given that one is forced to be explicit about the source of the function and given that there is no good solution, I guess using numpy.sin, etc. is best. Here's some timings of various possibilities on my machine: 0.20 import from math outside the function call 0.22 use math.sin and math.pi inside the function call 0.53 import from math inside the function call 0.67 import from numpy outside the function call 0.70 use numpy.sin and numpy.pi inside the function call 1.14 import from numpy inside the function call - Paul - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] sample canvas object code
On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm attaching the canvas object code I've been playing with.
>
> The API is still incomplete, but in the spirit of release early,
> release often, I'll put it out there for people to comment on.
Hey Paul this is really cool stuff. There is a minor bug -- the onAdd
callback in bindertest.py on line 26 should be onAddend I think.
Also, I wanted to know if you've looked that the copy_region/blit
stuff we have. It is specifically designed to speed up stuff like
this, where you want to move one or two artists across a stable
background.
http://www.scipy.org/Cookbook/Matplotlib/Animations
examples/poly_editor.py is similar to your example in that you click
and drag vertexes to modify the polygon, you can insert vertexes etc.
Obviously the API is clunky compared to the stuff you are doing (hence
the need for your extensions) but it does use the animation blit API
which you could borrow from if you haven't seen it. It may complicate
your code, so you can decide, but it would be a critical part of a
canvas like API I think. We could improve upon the blit API if
necessary to facilitate your work.
BTW, poly_editor was broken but I just fixed it so you can check it
out of svn if you want to take a look.
Right now I don't have any answers or comments to the questions you
raise in the code, eg on keyboard vs mouse focus handling -- you are
much deeper in this stuff than I am -- so I'll it's probably best if
you just keep thinking through these things as you go.
As for your traits question, you are absolutely right about the need
for a common callback framework. I have been cleaning up the
transformations in mpl1 and the callbacks and properties on the
affines are tremendously useful (eg xlim is just a property based view
into the affine, and one can connect to events on affine changes). I
don't have a GUI backend layer yet in which one can begin playing
around with interaction, but I am close, with a few more changes, to
having a serviceable first cut at the transformations, artist
hierarchy, and renderer layer.
FYI, every artist does have a callback mechanism built in which you
can easily extend to support additional events (right now I have been
adding them on as as needed basis -- what traits does so nicely is
that they are there for every traited instance).
Eg to connect to the Axes xlim:
ax.callbacks.connect('xlim_changed', func)
and func will be called with the signature func(ax). Eg see
examples/shared_axis_across_figures.py which utilizes the callbacks to
couple xlim across figure instances.
JDH
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl.math namespace
Eric Firing <[EMAIL PROTECTED]> writes: > 1) Present: always be explicit: npy.sin or ma.sin or math.sin or > cmath.sin. [...] > > 2) Pick a set of math symbols that may be imported directly from numpy > at the top, and either import all routinely, or import as needed. There's also an option that might be labeled 1a: import the necessary symbols in the function where they are used: def foobar(): from math import pi, sin, cos from numpy import arange, ones, zeros # ... This has the advantage that the documentation on what every symbol means is close to the code that uses the symbols, and the disadvantage of being slower because every call of the function causes a new import. This may or may not matter, depending on how often the function is called. -- Jouni K. Seppänen http://www.iki.fi/jks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Question about install matplotlib package (tk.tcl file on ubuntu)
Hi, During the installation of the matplotlib package, I was told that the matplotlib is trying to replace the tk.tcl file which belongs to the tk package Can anyone told me if this is a bug or feature Because of this conflict, I cannot install the package on my ubuntu Thanks Xuedong - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about install matplotlib package (tk.tcl file on ubuntu)
Sorry for my stupid question: What I am trying to run is the following command: sudo checkinstall python setup.py install I guess this maybe the problem between checkinstall and matplotlib Xuedong Xuedong Zhang 写道: > Hi, > During the installation of the matplotlib package, > I was told that the matplotlib is trying to replace the tk.tcl file > which belongs to the tk package > > Can anyone told me if this is a bug or feature > > Because of this conflict, I cannot install the package on my ubuntu > > Thanks > Xuedong > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about install matplotlib package (tk.tcl file on ubuntu)
Xuedong Zhang wrote: > Hi, > During the installation of the matplotlib package, > I was told that the matplotlib is trying to replace the tk.tcl file > which belongs to the tk package > > Can anyone told me if this is a bug or feature I don't know what to call it, but if it exists it is in the ubuntu package dependency system, not in matplotlib itself. Also, the version of matplotlib in ubuntu is pretty old, so I advise installing the latest release from source instead. See http://matplotlib.sourceforge.net/. Eric > > Because of this conflict, I cannot install the package on my ubuntu > > Thanks > Xuedong > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about install matplotlib package (tk.tcl file on ubuntu)
On Sat, Jul 21, 2007 at 05:50:19PM -0400, Xuedong Zhang wrote: > What I am trying to run is the following command: > sudo checkinstall python setup.py install > I guess this maybe the problem between checkinstall and matplotlib OK, now it's more clear. I suggest you install to /usr/local. That way you will get rid of this conflict. You should be able to do it this way: sudo checkinstall python setup.py install --prefix /usr/local Hope this helps, Gaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > I'm working on converting our existing rc code to tconfig this weekend.
> > So far so good. I just wanted to let people know to avoid duplicating
> > effort.
>
> Excellent! Ping me if you have any problems.
Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
whatever seems standard), and a backup of that .conf file. The mpltest lets
me try your trick of modifying a well formatted file in place. Very nice!
A couple comments:
1) Comments in the config file must appear on a separate line from the
parameters, or they will be overwritten
2) It would be nice to be able to write a default file that has everything
commented out with the exception of backend.use and numerix. We comment out
all the parameters in the current matplotlibrc, which makes it easier to
identify what has been customized during troubleshooting.
3) Any key appearing in the conf file is validated, so you cant mispell a key
name or accidentally include some garbage. But after generating the MPLConfig
object mplrc, you can do something like mplrc.nonsense = 1 without generating
an error. Is there a way to prevent the creation of additional attributes
once mplrc has been instantiated? That was a useful improvement to our
current rcParams.
4) It would be nice to create a new mpl.conf file based on changes made
interactively, without having to overwrite the old file, yet still preserving
the order and comments seen in the default I attached. Maybe copying the
default into the new location, and using it as the template? Even better,
when I saved a new file, it would preserve the defaults order, and any
settings that are identical to the defaults would be commented out. Ok, I'm
getting carried away. sorry.
> I'm going to try and finish hierarchical inclusion of files (aka
> ipython profiles) now. Consider for example a paper that requires
> black and white only styles. You could then have in that paper's
> directory a .matplotlib.conf file with:
>
> # paper-specific tweaks
> include = "$HOME/.matplotlib/matplotlib.conf"
>
> [lines]
> color = 'black'
> thickness = 2
>
> etc.
Thats a nice idea.
> Or in your .matplotlib dir, you could keep multiple configurations
> that branch off the basic one for different needs, while keeping
> common defaults in one central location.
>
> In my first implementation I'll have to give up on safe roundtripping
> to files with recursion active, because it's a bit tricky to do both
> (not impossible).
I'm feeling a bit cross-eyed from coding all day, and this is a little too
abstract at the moment for my poor head. Good luck!
Darren
Index: mpltest.py
===
--- mpltest.py (revision 2532)
+++ mpltest.py (working copy)
@@ -5,43 +5,14 @@
import mplconfig; reload(mplconfig)
from mplconfig import MPLConfig
-# Main code
-app = App(MPLConfig,'mpl2.conf')
-
-print app.rc
-
-# some more examples:
-print '-'*80
-print "Here is a default mpl config generated purely from the code:"
-mplrc = MPLConfig()
-print mplrc
-
-print '-'*80
-print "And here is a modified one, using a config file that only changes"
-print "a few parameters and otherwise uses the defaults:"
-mpl2conf = mkConfigObj('mpl2.conf')
-mplrc2 = MPLConfig(mpl2conf)
-print mplrc2
-
-# An example of the ConfigManager usage.
-m3conf = 'mpl3.conf'
-if os.path.isfile(m3conf):
-os.unlink(m3conf)
-mplconf = ConfigManager(MPLConfig,m3conf)
+m3conf = 'mplrc.conf'
+mplconf = ConfigManager(MPLConfig, m3conf, filePriority=True)
+mplconf.tconf.backend.use = 'Qt4Agg'
mplconf.write()
-print '-'*80
-print "The file %r was written to disk..." % m3conf
-os.system('more %s' % m3conf)
-if 0:
-print '-'*80
-print "Play with the 'mpl' object a little, esp its .rc attribute..."
-print "You can even do mpl.rc.edit_traits() if you are running in "
-print "ipython -wthread. It only works with the top-level for now."
-print
-print "The following is an auto-generated dump of the rc object."
-print "Note that this remains valid input for an rc file:"
-print
-mpl = App(MPLConfig,'mpl.conf')
-print mpl.rc
+##mplrc = mplconf.tconf
+##
+##mplrc.nonsense = 1
+##
+##print mplrc
Index: mplrc.conf
===
--- mplrc.conf (revision 0)
+++ mplrc.conf (revision 0)
@@ -0,0 +1,443 @@
+### MATPLOTLIBRC FORMAT
+
+# This is a sample matplotlib configuration file. It should be placed
+# in HOME/.matplotlib/matplotlibrc (unix/linux like systems) and
+# C:\Documents and Settings\yourname\.matplotlib (win32 systems)
+#
+# By default, the installer will overwrite the existing file in the
+# install path, so if you want to preserve your's, please move it to
+# your HOME dir and set the environment variabl
Re: [matplotlib-devel] sample canvas object code
On Sat, Jul 21, 2007 at 02:39:52PM -0500, John Hunter wrote:
> On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I'm attaching the canvas object code I've been playing with.
> >
> > The API is still incomplete, but in the spirit of release early,
> > release often, I'll put it out there for people to comment on.
>
> Hey Paul this is really cool stuff. There is a minor bug -- the onAdd
> callback in bindertest.py on line 26 should be onAddend I think.
onAppend. That's a brown paper bagger :-(
> Also, I wanted to know if you've looked that the copy_region/blit
> stuff we have.
I'm aware of the blit stuff but haven't looked in detail. So far I
don't need it because my graphs are simple. Later when I define
widgets operating on meshes I will look more closely.
> BTW, poly_editor was broken but I just fixed it so you can check it
> out of svn if you want to take a look.
Yup, it works now! Even when it was broken it was still a good source
of examples.
> Right now I don't have any answers or comments to the questions you
> raise in the code, eg on keyboard vs mouse focus handling -- you are
> much deeper in this stuff than I am -- so I'll it's probably best if
> you just keep thinking through these things as you go.
I'll be away for a weeks but will continue when I return. Working
with it when I return.
I already know that I need to use keyboard focus handling. My real
application can move objects around on the screen with the keyboard
for finer control, and this will only work if the keyboard focus stays
with the object even as it moves from the mouse.
> As for your traits question, you are absolutely right about the need
> for a common callback framework. I have been cleaning up the
> transformations in mpl1 and the callbacks and properties on the
> affines are tremendously useful (eg xlim is just a property based view
> into the affine, and one can connect to events on affine changes). I
> don't have a GUI backend layer yet in which one can begin playing
> around with interaction, but I am close, with a few more changes, to
> having a serviceable first cut at the transformations, artist
> hierarchy, and renderer layer.
I'm looking forward to seeing it.
> FYI, every artist does have a callback mechanism built in which you
> can easily extend to support additional events (right now I have been
> adding them on as as needed basis -- what traits does so nicely is
> that they are there for every traited instance).
>
> Eg to connect to the Axes xlim:
>
> ax.callbacks.connect('xlim_changed', func)
>
> and func will be called with the signature func(ax). Eg see
> examples/shared_axis_across_figures.py which utilizes the callbacks to
> couple xlim across figure instances.
How much control is there over the which callbacks are called, what order
they are called in, and when effects show up on the screen?
My first implementation sends the event to the artist, and if the artist
returns false it goes to the axes, then the figure. This is much weaker
than the Tk/BLT canvas model, which allows the programmer to control the
order, and also has class-based dispatch.
Also, I'm nervous about this from a performance perspective --- I don't want
others to have a slower graphics engine just because I need callbacks
for what I'm doing.
Has anyone done profiling to see where the current bottlenecks are?
I know we will be looking into this; the user experience was so
awkward with four plotting panels in an wx.aui frame that we went
back to a straight wx.lib.plot backend.
- Paul
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mathtext baseline
Hi,
I really love mathtext! I wrote a simple formula parser
and now I can label my graphs with easy to read chemical
names (I've attached it below for the curious).
The problem is that the baseline is wandering. On my machine
the following has the 'h' too low and the 'io' too high:
import pylab
ax = pylab.subplot(111)
pylab.text(0.5,0.5,r'$\rm{Thiol}$', va='bottom')
pylab.show()
I'm using wxAgg on OS X. I know I've installed freetype, but
beyond that I have no idea what font it is using.
Do others experience the same problem?
Any idea where I can start when debugging this?
- Paul
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote: > On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote: > > On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > > I'm working on converting our existing rc code to tconfig this weekend. > > > So far so good. I just wanted to let people know to avoid duplicating > > > effort. > > > > Excellent! Ping me if you have any problems. > > Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic > mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or > whatever seems standard), and a backup of that .conf file. The mpltest lets > me try your trick of modifying a well formatted file in place. Very nice! Is the patch against current SVN? I'm in a hurry and can't look at it now, so if you can double-check, that would be great. For tconfig.py, my last commit was: Last Changed Rev: 2532 Last Changed Date: 2007-07-21 15:19:06 -0600 (Sat, 21 Jul 2007) > A couple comments: > > 1) Comments in the config file must appear on a separate line from the > parameters, or they will be overwritten > > 2) It would be nice to be able to write a default file that has everything > commented out with the exception of backend.use and numerix. We comment out > all the parameters in the current matplotlibrc, which makes it easier to > identify what has been customized during troubleshooting. John and I just had a long conversation on this topic, and I think we have a reasonable solution. I have to run now, but I'll try to implement it tomorrow and will get back to you with more feedback. Sorry but I have guests coming now :) > 3) Any key appearing in the conf file is validated, so you cant mispell a key > name or accidentally include some garbage. But after generating the MPLConfig > object mplrc, you can do something like mplrc.nonsense = 1 without generating > an error. Is there a way to prevent the creation of additional attributes > once mplrc has been instantiated? That was a useful improvement to our > current rcParams. Yes, we can inherit from HasStrictTraits instead of HasTraits. I was in fact doing that but had some problem, can't remember what. I'm sure it's doable though. > 4) It would be nice to create a new mpl.conf file based on changes made > interactively, without having to overwrite the old file, yet still preserving > the order and comments seen in the default I attached. Maybe copying the > default into the new location, and using it as the template? Even better, > when I saved a new file, it would preserve the defaults order, and any > settings that are identical to the defaults would be commented out. Ok, I'm > getting carried away. sorry. > > > I'm going to try and finish hierarchical inclusion of files (aka > > ipython profiles) now. Consider for example a paper that requires > > black and white only styles. You could then have in that paper's > > directory a .matplotlib.conf file with: > > > > # paper-specific tweaks > > include = "$HOME/.matplotlib/matplotlib.conf" > > > > [lines] > > color = 'black' > > thickness = 2 > > > > etc. > > Thats a nice idea. > > > Or in your .matplotlib dir, you could keep multiple configurations > > that branch off the basic one for different needs, while keeping > > common defaults in one central location. > > > > In my first implementation I'll have to give up on safe roundtripping > > to files with recursion active, because it's a bit tricky to do both > > (not impossible). > > I'm feeling a bit cross-eyed from coding all day, and this is a little too > abstract at the moment for my poor head. Good luck! Yup, I'm pretty tired too. It seems we're all in the same carpal-tunnel-inducing marathon :) Thanks again for pitching in! Cheers, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mathtext baseline
On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I really love mathtext! I wrote a simple formula parser
> and now I can label my graphs with easy to read chemical
> names (I've attached it below for the curious).
>
> The problem is that the baseline is wandering. On my machine
> the following has the 'h' too low and the 'io' too high:
Just guessing, but...
There is a problem we have with text alignment in the ft2font module.
We can either align to top, bottom or center, but we need an option to
align to the glyph baseline. Michael is currently working on mathtext
and is now our resident font guru. Michael, can you take a look at
this. This would be an important enhancement for mathtext, multiline
text, and a text entry widget.
Thanks,
JDH
>
> import pylab
> ax = pylab.subplot(111)
> pylab.text(0.5,0.5,r'$\rm{Thiol}$', va='bottom')
> pylab.show()
>
> I'm using wxAgg on OS X. I know I've installed freetype, but
> beyond that I have no idea what font it is using.
>
> Do others experience the same problem?
>
> Any idea where I can start when debugging this?
>
> - Paul
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
