matplotlib-devel Mailing List for matplotlib (Page 6)

On Sat, Jul 21, 2007 at 02:39:52PM -0500, John Hunter wrote:
> On 7/21/07, Paul Kienzle <pki...@ni...> 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

On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> On 7/21/07, Darren Dale <dd...@co...> 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

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

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

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

Eric Firing <ef...@ha...> 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

On 7/21/07, Paul Kienzle <pki...@ni...> 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

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

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 tgamma 0 fmax
> 44 abs 3 tan 0 signbit 0 fdim
> 38 sin 3 nan 0 scalbn 0 expm1
> 28 cos 3 log2 0 rint 0 exp2
> 23 minimum 3 hypot 0 remquo 0 erfc
> 22 round 2 isnan 0 nexttoward 0 erf
> 19 maximum 2 arctan 0 nearbyingt 0 cproj
> 19 floor 2 arcsin 0 modf 0 copysign
> 18 log10 2 arccos 0 logb 0 conj
> 18 ceil 1 tanh 0 log1p 0 cbrt
> 13 real 1 sinh 0 lgamma 0 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

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

On Friday 20 July 2007 5:13:12 pm Fernando Perez 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'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

On 7/21/07, Eric Firing <ef...@ha...> 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

On 7/21/07, Paul Kienzle <pki...@ni...> 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

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

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

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

On Sat, Jul 21, 2007 at 09:42:16AM -0500, John Hunter wrote:
> On 7/21/07, Paul Kienzle <pki...@ni...> wrote:
> > I used the following list:
> >
> > symlist=`cat <<EOF
> > 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 "<stdin>", line 1, in <module>
 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

On 7/21/07, Gael Varoquaux <gae...@no...> 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

On 7/21/07, Paul Kienzle <pki...@ni...> wrote:
> I used the following list:
>
> symlist=`cat <<EOF
> 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

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 tgamma 0 fmax
44 abs 3 tan 0 signbit 0 fdim
38 sin 3 nan 0 scalbn 0 expm1
28 cos 3 log2 0 rint 0 exp2
23 minimum 3 hypot 0 remquo 0 erfc
22 round 2 isnan 0 nexttoward 0 erf
19 maximum 2 arctan 0 nearbyingt 0 cproj
19 floor 2 arcsin 0 modf 0 copysign
18 log10 2 arccos 0 logb 0 conj
18 ceil 1 tanh 0 log1p 0 cbrt
13 real 1 sinh 0 lgamma 0 NaN
12 exp 1 fmod 0 ldexp 0 Inf
I used the following list:
symlist=`cat <<EOF
 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
of this discussion. Tuning the list to the set of functions
available in numpy rather than c99 would help (I did rename
ayyy to arcyyy for the trig functions).
- Paul

On Tue, Jul 17, 2007 at 08:17:50PM -0500, John Hunter wrote:
> On 7/17/07, Gael Varoquaux <gae...@no...> 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

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

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

On Jul 20, 2007, at 5:53 PM, Christopher Barker wrote:
> However, I have seen a real shift on the numpy list over the last year
> (or two), toward using the namespace.
Yes, I do that to, primarily in scripts. However, for interactive 
sessions, I usually import into the top namespace. I imagine others 
might as well. Particularly people coming from environments like 
matlab will initially want everything up top.
Separate namespaces are great. I still think from
	pylab import *
should not overlap with from
	numpy import *
I don't think it would be hard to make sure that there are no 
duplicate function names in the top namespace. E.g., mpl load could 
be put in mpl, matplotlib, or mpl_io, or something similar.
People will migrate to separate namespaces eventually, as they get 
more familear with python, but they will be annoyed initially with 
any overlaps.
-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