# Polygon examples broken

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

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

···

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

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

Chris.Barker@...236...