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 <<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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
