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

>>> 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 dofrom 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 Sat, Jul 21, 2007 at 09:42:16AM -0500, John Hunter wrote:

On 7/21/07, Paul Kienzle <pkienzle@...537...> wrote: