matplotlib-devel Mailing List for matplotlib

On Fri, Jul 20, 2007 at 02:53:42PM -0700, Christopher Barker wrote:
> Paul Kienzle wrote:
> > On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote:
> >> Out of 491 names in the numpy namespace, I found 26 that would commonly 
> >> be found in math expressions. 
> 
> > The C99 math/complex headers define a number of symbols.
> 
> Sure, but you don't need all of those. My idea was thus:
> 
> "Namespaces are one honking great idea"
> 
> but they are kind of ugly inside math expressions. But:
> 
> "Practicality beats purity"
> 
> so I think it does make sense to bring the common names that show up in 
> math expressions into the main namespace. Not all the handy little names 
> ( like isnan, zeros, linspace, etc.) only the ones that show up in the 
> depths of nested math expressions, so that we can write code that looks 
> like math. That's how I came up with my personal list of 26.
> 
> 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.
I suppose one approach is to go through all of mpl, find what is being
imported with what frequency, and build the list based on that.
Maybe I will get a chance this weekend. Right now I have to go back to 
the "matplotlib svn doesn't build on windows" problem.
	- Paul

Robert Kern wrote:
> Rob Hetland wrote:
>> There is also quite a bit of advice on the internet and otherwise 
>> that 'from numpy import *' is the way to import the library. For 
>> example, this is the approach in Oliphant's 'Guide to Numpy.'
> 
> You'll often see it in examples because it's the only way to make examples clear
> and to the point. It's not a recommendation.
Indeed. way back when, in the days of Numeric, it WAS the 
recommendation, then we were in a state of flux, and as Robert said, 
many quick examples are still written using "import *".
However, I have seen a real shift on the numpy list over the last year 
(or two), toward using the namespace.
Paul Kienzle wrote:
> On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote:
>> Out of 491 names in the numpy namespace, I found 26 that would commonly 
>> be found in math expressions. 
> The C99 math/complex headers define a number of symbols.
Sure, but you don't need all of those. My idea was thus:
"Namespaces are one honking great idea"
but they are kind of ugly inside math expressions. But:
"Practicality beats purity"
so I think it does make sense to bring the common names that show up in 
math expressions into the main namespace. Not all the handy little names 
( like isnan, zeros, linspace, etc.) only the ones that show up in the 
depths of nested math expressions, so that we can write code that looks 
like math. That's how I came up with my personal list of 26.
This is probably best just done by each individual according to his/her 
taste.
Rob Hetland wrote:
> I get namespaces. They are really great. It's just that I use numpy 
> and mpl *so* much that the namespaces get in the way.
Maybe using Paul's suggestion of having a "math" namespace that you 
"import *" would help.
Or use "from pylab import *" and reference just the numpy names you want 
separately.
> And really, numpy and mpl coexist beautifully, except for a few small 
> exceptions. 'load' is one. (There are others I have run across as well).
> 
> I think mpl should play nice even for folks like me who occasionally 
> like to abandon separate namespaces.
But it does. numpy was designed pretty much to do just that -- give you 
one big namespace to import. And it provides the numerix interface as 
part of that.
However, if you do that, you have to deal with the decisions MPL 
developers make. numpy is designed by a separate team, and is not 
designed to be "import *"ed into the pylab namespace (I think it is 
designed not to clash with the python built-ins at least). This is a 
common issue with packages developed by different people for similar 
purposes, and python already has namespaces as a great way to deal with it!
Indeed, in this case, I suppose it's the numpy folks that aren't 
"playing nice" -- numpy.load was added after pylab.load was already 
there. But it's not a goal of the numpy team to be name-compatible with 
pylab.
-Chris
This is really is pretty OT for the devel list, though, so I'll stop here.
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 7/20/07, Darren Dale <dd...@co...> wrote:
> On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote:
> > I also just (r2528) updated things to use a cleaner import convention:
> > I don't like importing things from modules *they* imported.
> [...]
> > 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.
>
> I was thinking along the lines of your config/api.py file, a single entry
> point to the ipython or mpl config API.
Ah, OK. Since we haven't really organized such an api yet, I was
still thinking of the individual components. I see your point.
Cheers,
f

On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote:
> I also just (r2528) updated things to use a cleaner import convention:
> I don't like importing things from modules *they* imported.
[...]
> 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.
I was thinking along the lines of your config/api.py file, a single entry 
point to the ipython or mpl config API.

On 7/20/07, Fernando Perez <fpe...@gm...> wrote:
> On 7/20/07, Darren Dale <dd...@co...> 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 also just (r2528) updated things to use a cleaner import convention:
I don't like importing things from modules *they* imported. To
clarify:
planck[tconfig]> svn diff -r2527:2528 mpltest.py
Index: mpltest.py
===================================================================
--- mpltest.py (revision 2527)
+++ mpltest.py (revision 2528)
@@ -1,5 +1,11 @@
-from mplconfig import MPLConfig, ConfigManager, mkConfigObj
+# import/reload base modules for interactive testing/development
+import tconfig, mplconfig
+reload(tconfig)
+reload(mplconfig)
+from tconfig import ConfigManager, mkConfigObj
+from mplconfig import MPLConfig
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.
The reload tricks also allow me to continue running the top-level test
codes while mucking with the stuff underneath, and have changes make
their way through consistently.
Thanks again,
f

On 7/20/07, Darren Dale <dd...@co...> 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.
Cheers,
f

Fernando Perez wrote:
> Am I missing something?
No, I just wasn't paying close enough attention. Never mind me.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On 7/20/07, Robert Kern <rob...@gm...> wrote:
> Darren Dale wrote:
>
> > That is not too bad for small config files, but matplotlib's selection of rc
> > parameters is pretty large, and it is nice to have them appear in the file in
> > a meaningful order.
>
> You guys may want to consider iniparse instead of configobj. It will preserve
> order, indentation, comments(!), and blank lines.
>
> http://code.google.com/p/iniparse/
>
> The drawback is that it doesn't support nested sections, to my knowledge. There
> might also be more special features of configobj that Fernando uses; I haven't
> taken a very close look at the code, yet.
Mmh, but configobj does preserve all those as well. Darren's comment
was about not being able to get a clean file when made purely from a
HasTraits description. But when there is an existing file on disk,
configobj is actually really good at preserving it.
So it seems to me that iniparse appears to be a limited subset of
configobj (we really want nested sections in ipython, and MPL has them
as well already). It does have the a.b instead of a['b'] convenience,
but we get that via traits anyway.
Am I missing something?
Cheers,
f

Rob Hetland wrote:
> There is also quite a bit of advice on the internet and otherwise 
> that 'from numpy import *' is the way to import the library. For 
> example, this is the approach in Oliphant's 'Guide to Numpy.'
You'll often see it in examples because it's the only way to make examples clear
and to the point. It's not a recommendation.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Paul Kienzle wrote:
> Let me rephrase: Can we have a function sqrt(x) which returns real if x is
> nonnegative, and complex if it is negative? Similarly for other math functions
> such as log which produce complex values for negative numbers?
> 
> I suppose the numpy list is the place to debate this, but it seems like it
> ought to be a feature of pylab in as much as pylab helps matlab users do
> pythonic things in a familiar environment.
numpy.sqrt() won't do that (we've already discussed it). scipy.sqrt() does,
though. The functions that work like this are in numpy.lib.scimath.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Darren Dale wrote:
> That is not too bad for small config files, but matplotlib's selection of rc 
> parameters is pretty large, and it is nice to have them appear in the file in 
> a meaningful order.
You guys may want to consider iniparse instead of configobj. It will preserve
order, indentation, comments(!), and blank lines.
 http://code.google.com/p/iniparse/
The drawback is that it doesn't support nested sections, to my knowledge. There
might also be more special features of configobj that Fernando uses; I haven't
taken a very close look at the code, yet.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote:
> You're right that for math expressions, it is nice to have them in the 
> namespace, so this is used a lot:
> 
> from numpy import sqrt, sin, cos, exp
> 
> Maybe it's a reasonable idea to write a Nmath.py, which would have an 
> import line like that.
> 
> Out of 491 names in the numpy namespace, I found 26 that would commonly 
> be found in math expressions. Not bad, really, much better than 
> including all 491.
> 
> Inf NaN abs angle arccos arccosh arcsin arcsinh arctan
> arctan2 arctanh cos cosh exp log log10 pi sign sin
> sinc sinh sqrt square tan tanh
The C99 math/complex headers define a number of symbols.
constants: 
 log: M_E M_LOG2E M_LOG10E M_LN2 M_LN10
 pi: M_PI M_PI_2 M_PI_4 M_1_PI M_2_PI M_2_SQRTPI
 sqrt(2): M_SQRT2 M_SQRT1_2
functions: 
 isfinite isnormal isnan isinf
 acos asin atan atan2 cos sin tan
 acosh asinh atanh 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
complex functions:
 acos asin atan atan2 cos sin tan
 acosh asinh atanh cosh sinh tanh
 exp log pow sqrt
 conj cproj abs arg imag real
The glibc header files are not the most concise source so likely I've
made mistakes (e.g., missing inf/nan defs) and included things that
are not actually standard (e.g., hypot?). Making a lot of these available
in mpl.math would be nice.
Short of installing all of scipy, anyone know where I can pick up erf()?
> > I'm guessing a function sqrt(-1.) which returns 1j is out of the question?
> 
> what's wrong with "1j" as a literal?
Let me rephrase: Can we have a function sqrt(x) which returns real if x is
nonnegative, and complex if it is negative? Similarly for other math functions
such as log which produce complex values for negative numbers?
I suppose the numpy list is the place to debate this, but it seems like it
ought to be a feature of pylab in as much as pylab helps matlab users do
pythonic things in a familiar environment.
	- Paul

On Jul 20, 2007, at 2:02 PM, Christopher Barker wrote:
> That's why: "Namespaces are one honking great idea". They really are.
> Trust me on this.
I get namespaces. They are really great. It's just that I use numpy 
and mpl *so* much that the namespaces get in the way. Most of my 
(smaller) coding errors involve forgetting 'pl.' in front of an mpl 
function.
There is also quite a bit of advice on the internet and otherwise 
that 'from numpy import *' is the way to import the library. For 
example, this is the approach in Oliphant's 'Guide to Numpy.'
And really, numpy and mpl coexist beautifully, except for a few small 
exceptions. 'load' is one. (There are others I have run across as 
well).
I think mpl should play nice even for folks like me who occasionally 
like to abandon separate namespaces.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Friday 20 July 2007 03:01:19 pm you wrote:
> On 7/20/07, Fernando Perez <fpe...@gm...> wrote:
> > However, it's not all gloom and doom: one can simply generate a config
> > file from the object description, edit it for ordering, and after that
> > keep it synced with changes to the object description fairly easily.
> > The current code only works in one direction: the file overrides the
> > object. It should take me about 5 minutes to add a method to go in
> > the other, since the code is really already there. With that, you can
> > then use the workflow of generating once, manually fixing it, and then
> > updating it from the class.
> >
> > That way, you can always keep the default file you like as internal
> > MPL data, but at install time, update that file as needed from runtime
> > config before putting it in the user's directory. It lets you keep a
> > nicely commented, organized file, but update it at installation time
> > with proper info.
> >
> > I'll code this up after I get back from lunch, and then I'll really
> > stop touching this code. I mean it :)
>
> Nah, whoo needs lunch. Done:
>
> svn commit -m"Add option for class defaults to override files, so
> projects can impose changing defaults on files. After Darren's
> suggestion for MPL."
>
> This should give you a very reasonable solution for what you wanted to do.
Great! I'm surprised that this was possible.
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.
Darren

On 7/20/07, Gael Varoquaux <gae...@no...> wrote:
> This question really belongs to the user ML, but I don't want to
> subscribe to another ML, so please, indulge me.
>
> I often have a figure with a lot of plot, some of them created in a for
> loop. I want some of them to display in the legend, and some of them not
> to. Now this is possible, using the two positionnal argument form of
> "legend", but this means I have to keep trak of all the plots created,
> and of the associated label. Is there a way to specify that a plot should
> not have a legend when creating it. Something like "plot( ...,
> label=False)" would be great.
>
> If not, would it be possible to have such a feature ?
In recent mpl, label='' should do it. In order versions, label='_nolegend_'
>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.

On 7/20/07, Christopher Barker <Chr...@no...> wrote:
> > On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
> >> I also plan to use the SWIG agg wrapper
>
> Where can I find that? I did some googling, and no luck.
mpl1/mpl1.py uses it.... It is available in matplotlib installs as
from matplotlib import agg.
The SWIG code is in the swig dir in mpl svn, and there is a partially
broken example in examples/agg_test.py
JDH

This question really belongs to the user ML, but I don't want to
subscribe to another ML, so please, indulge me.
I often have a figure with a lot of plot, some of them created in a for
loop. I want some of them to display in the legend, and some of them not
to. Now this is possible, using the two positionnal argument form of
"legend", but this means I have to keep trak of all the plots created,
and of the associated label. Is there a way to specify that a plot should
not have a legend when creating it. Something like "plot( ...,
label=False)" would be great.
If not, would it be possible to have such a feature ?
Cheers,
Gaël

> On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
>> I also plan to use the SWIG agg wrapper
Where can I find that? I did some googling, and no luck.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Paul Kienzle wrote:
> This is improved somewhat as:
> 
> import numpy as N
> res = N.sqrt(2*N.sin(N.pi*x**2) + N.cos(x**2) - N.exp(2*N.pi*1j))
> 
> but the following is better:
> 
> from mpl.math import *
> res = sqrt(2*sin(pi*x**2) + cos(x**2) - exp(2*pi*1j))
quite true. Interestingly, I find that expressions like that are not a 
large fraction of my code these days -- maybe that's a bad thing, I used 
to do math!
> Can we create a math.py which makes a standard set of math functions
> available?
You're right that for math expressions, it is nice to have them in the 
namespace, so this is used a lot:
from numpy import sqrt, sin, cos, exp
Maybe it's a reasonable idea to write a Nmath.py, which would have an 
import line like that.
Out of 491 names in the numpy namespace, I found 26 that would commonly 
be found in math expressions. Not bad, really, much better than 
including all 491.
Inf
NaN
abs
angle
arccos
arccosh
arcsin
arcsinh
arctan
arctan2
arctanh
cos
cosh
exp
log
log10
pi
sign
sin
sinc
sinh
sqrt
square
tan
tanh
> I'm guessing a function sqrt(-1.) which returns 1j is out of the question?
what's wrong with "1j" as a literal?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Fri, Jul 20, 2007 at 09:03:21AM -1000, Eric Firing wrote:
> Good, thank you. This brings up the larger question of the major 
> redesign that is underway, and how to make sure we don't lose the 
> benefit of wonderful speedups like quadmesh. How hard would it be to 
> translate it to use the swig-wrapped version of agg rather than 
> accessing agg directly via the present pycxx _backend_agg.cpp? And how 
> much performance do you think would be lost? Alternatively, is there a 
> better way to put the fast rendering capability in a smaller piece of 
> extension code that can be used in the new framework and that would not 
> rely on pycxx? E.g., a small swiggable chunk?
It is a long time since I've looked at the code, and I wasn't even
the original author. Furthermore I don't know swig, nor am I particularly
familiar with pycxx, so I can't answer your question. 
I imagine given an agg context, however that is usually done, that a 
walk of some arrays is all we need to do. Simplifying the 
representations on the python side will help a lot IIRC. 
The interface to my OpenGL plotter (not pylab enabled, sorry!) 
wasn't complex.
Anyway, I'll be gone next week until mid-August, so don't expect 
anything before the end of summer. 
	- Paul

On 7/20/07, Eric Firing <ef...@ha...> wrote:
> ngs up the larger question of the major
> redesign that is underway, and how to make sure we don't lose the
> benefit of wonderful speedups like quadmesh. How hard would it be to
> translate it to use the swig-wrapped version of agg rather than
> accessing agg directly via the present pycxx _backend_agg.cpp? And how
> much performance do you think would be lost? Alternatively, is there a
> better way to put the fast rendering capability in a smaller piece of
> extension code that can be used in the new framework and that would not
> rely on pycxx? E.g., a small swiggable chunk?
One can fairly easily add custom extension code into the SWIG wrappers
themselves. A single example is swig/agg_buffer.h, a small C++ class
I added to expose the underlying image buffer to python. We would
definitely port over stuff like quadmesh, where the hard part is not
in the python wrapper interface, but in the code and algorithm itself,
which should port fairly easily.
JDH
JDH

On Fri, Jul 20, 2007 at 11:02:45AM -0700, Christopher Barker wrote:
> Rob Hetland wrote:
> > First, it has bothered me that from pylab import * and from numpy 
> > import * both import 'load' statements. Yes, I realize that I can put 
> > them in their own name space, but I only use python for mpl and numpy 
> 
> 
> That's why: "Namespaces are one honking great idea". They really are. 
> Trust me on this.
> 
> Also, doesn't pylab hold all of numerix anyway? Why do you need both?
> 
> If you want to use the latest numpy API (which I do) then again -- 
> "Namespaces are one honking great idea". This is what they are for.
> 
> Otherwise, you're stuck with using numerix and waiting until MPL goes 
> pure numpy ( I don't know when that might be). pylab and numpy stomp all 
> over each other (if you use import *) by design.
> 
> It comes down to this: if you use "import *" you're forced to use the 
> decision made by others -- the numerix API, which, quite reasonably, 
> they are keeping backward compatible.
> 
> Is it really that hard to use this?
> 
> import numpy as N # or "as npy", the mpl standard.
> 
> a = N.arange(10)
> 
> a.sum()
> 
> etc, etc...
> 
> One of the nice things about numpy is that there are lot more array 
> methods, rather than functions, so it works better with namespaces -- 
> you really don't need to type the "N." all that much.
> 
> from pylab import *
> import numpy as N
> 
> May be a reasonable compromise.
> 
> > -- for me python is a matlab replacement.
> 
> In many ways it is for me too, but it's so much better! take advantage 
> of the advantages -- like namespaces.
> 
> If you're anything like me, you may not be writing big programs, but 
> even quickie scripts are edited and re-edited a lot -- a little extra 
> typing makes little difference.
> 
> -Chris
To throw out some nonsense:
 import numpy as npy
 res = npy.sqrt(2*npy.sin(npy.pi*x**2) + npy.cos(x**2) - npy.exp(2*npy.pi*1j))
is not very readable. 
This is improved somewhat as:
 import numpy as N
 res = N.sqrt(2*N.sin(N.pi*x**2) + N.cos(x**2) - N.exp(2*N.pi*1j))
but the following is better:
 from mpl.math import *
 res = sqrt(2*sin(pi*x**2) + cos(x**2) - exp(2*pi*1j))
Can we create a math.py which makes a standard set of math functions
available? Posix libc is an excellent place to start, though I would
also appreciate inf, nan, pi and eps as well.
I'm guessing a function sqrt(-1.) which returns 1j is out of the question?
 - Paul

Paul Kienzle wrote:
[...]
>> Quadmesh has a bug in it that I would love to see squashed. Can you 
>> look at it, or induce someone else to do so? I tried but couldn't 
>> figure it out--it is something deep in the use of Agg. It is illustrated 
>> by examples/quadmesh_demo.py. With masked data (right-hand subplot), 
>> the masked region is not set to the background but is instead picking up 
>> odd things. If you don't see it immediately, try reshaping and resizing 
>> the plot a few times.
> 
> We should be able to track it down. We need to go deep in the code
> again anyway to figure out why performance bogs when zooming. We
> won't be touching it before the end of summer though.
> 
> 	- Paul
Good, thank you. This brings up the larger question of the major 
redesign that is underway, and how to make sure we don't lose the 
benefit of wonderful speedups like quadmesh. How hard would it be to 
translate it to use the swig-wrapped version of agg rather than 
accessing agg directly via the present pycxx _backend_agg.cpp? And how 
much performance do you think would be lost? Alternatively, is there a 
better way to put the fast rendering capability in a smaller piece of 
extension code that can be used in the new framework and that would not 
rely on pycxx? E.g., a small swiggable chunk?
Eric

On 7/20/07, Fernando Perez <fpe...@gm...> wrote:
> However, it's not all gloom and doom: one can simply generate a config
> file from the object description, edit it for ordering, and after that
> keep it synced with changes to the object description fairly easily.
> The current code only works in one direction: the file overrides the
> object. It should take me about 5 minutes to add a method to go in
> the other, since the code is really already there. With that, you can
> then use the workflow of generating once, manually fixing it, and then
> updating it from the class.
>
> That way, you can always keep the default file you like as internal
> MPL data, but at install time, update that file as needed from runtime
> config before putting it in the user's directory. It lets you keep a
> nicely commented, organized file, but update it at installation time
> with proper info.
>
> I'll code this up after I get back from lunch, and then I'll really
> stop touching this code. I mean it :)
Nah, whoo needs lunch. Done:
svn commit -m"Add option for class defaults to override files, so
projects can impose changing defaults on files. After Darren's
suggestion for MPL."
This should give you a very reasonable solution for what you wanted to do.
Now, I'll get lunch!
Cheers,
f

On Fri, Jul 20, 2007 at 06:57:26AM -1000, Eric Firing wrote:
> Paul Kienzle wrote:
> > On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote:
> >> Second, much of what I do involves plotting model data (on a 
> >> curvilinear grid). I generally like to use pcolor for these plots. 
> >> I *always* want shading='flat' Some of my grids are large, and I 
> >> only see lines if I don't. Even with smaller grids, those black 
> >> lines get in the way. I don't want to suggest an RC setting for 
> >> everything, but this one single setting would save me thousands of 
> >> characters typed per week. Can we add an RC shading option?
> > 
> > If your data is on a quadrilateral mesh, try using the pcolormesh
> > function. It is orders of magnitude faster than pcolor and we
> > solved the black lines problem by using transparency on the mesh
> > grid (though of course you can use 'flat' if you want). We only
> > implemented this for the Agg backend, otherwise it falls back to
> > the pcolor style rendering of a collection of polygons.
> 
> Paul,
> 
> Quadmesh has a bug in it that I would love to see squashed. Can you 
> look at it, or induce someone else to do so? I tried but couldn't 
> figure it out--it is something deep in the use of Agg. It is illustrated 
> by examples/quadmesh_demo.py. With masked data (right-hand subplot), 
> the masked region is not set to the background but is instead picking up 
> odd things. If you don't see it immediately, try reshaping and resizing 
> the plot a few times.
We should be able to track it down. We need to go deep in the code
again anyway to figure out why performance bogs when zooming. We
won't be touching it before the end of summer though.
	- Paul