Issue 1880: Generalize math.hypot function (original) (raw)

Please generalize math.hypot. While I don't have a survey of python codes, it seems to me unlikely for this change to break existing programs.

import math

def hypot(args): ''' Return the Euclidean vector length. >>> from math import hypot, sqrt >>> hypot(5,12) # traditional definition 13.0 >>> hypot() 0.0 >>> hypot(-6.25) 6.25 >>> hypot(1,1,1) == sqrt(3) # diagonal of unit box True ''' return math.sqrt(sum(argarg for arg in args))

I propose this version as closest to:

print sys.version 2.5.1 (r251:54863, Jan 4 2008, 17:15:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] print math.hypot.doc hypot(x,y)

Return the Euclidean distance, sqrt(xx + yy).

Thanks, Dave.

PS. I don't understand why python is so restrictive. Although hypot is in the math library, it could be written in EAFP style as

def hypot(args): return sum(argarg for arg in args)**0.5

Rather than review the entire python library for items to generalize, I'll accept that the resulting errors would confuse "the penguin on my tele". "hypot" crosses me most often. I've not yet needed a version in the complex domain, such as my second version.

I typically fill my need for length with scipy.sqrt(scipy.dot(v,v)), only to realize that for the short vectors I use, standard python constructs always perform faster than scipy

I'm not sure either that such a generalization would belong in math (which right now does little more than expose some basic functions from the C library) or that it should be called hypot.

It seems to me that this would belong with other vector-type math stuff, but there isn't any of that in core Python or the libraries at the moment.

On one hand, this falls foul of the 'not every one-liner should be a builtin' rule.
On the other hand, it's not a one-liner if done properly: compare the output of math.hypot(1e160, 1e160) with the output of your version. Similarly for math.hypot(1e-160, 1e-160).