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