Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #91246
| From | random832@fastmail.us |
|---|---|
| References | <b2e66a94-7a89-4be9-bbf7-9434396cc178@googlegroups.com> <1432647653.1149540.278304225.25D9F2E4@webmail.messagingengine.com> |
| Subject | Re: a more precise distance algorithm |
| Date | 2015-05-26 09:51 -0400 |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.56.1432648319.5151.python-list@python.org> (permalink) |
On Tue, May 26, 2015, at 09:40, random832@fastmail.us wrote:
> On Mon, May 25, 2015, at 15:21, ravas wrote:
> > Is this valid? Does it apply to python?
> > Any other thoughts? :D
>
> The math.hypot function uses the C library's function which should deal
> with such concerns internally. There is a fallback version in case the C
> library does not have this function, in Python/pymath.c - which,
> incidentally, does use your algorithm.
Well, I should say, not _precisely_ your algorithm.
The "0 special case" mentioned in the text you read was for both values
being zero, not just one. The biggest flaw in your function, though, was
the failure to take the absolute values of the differences. This defeats
the point of swapping them (which I assume is to get the magnitudes in
the order needed for best precision), and makes it possible for your
function to return a negative value when the other is zero.
Here's the equivalent python code for the hypot function in pymath.c,
and for your distance function.
from math import sqrt
def hypot(x, y):
x = abs(x)
y = abs(y)
if x < y:
x, y = y, x
if x == 0: # both are 0 due to the swap
return 0.0
else:
return x*sqrt(1.0 + (y/x)**2)
def distance(A, B):
return hypot(A.x-B.x, A.y-B.y)
What I wonder is if there's a best way to do it for three dimensions. I
mean, you could simply do hypot(hypot(dx, dy), dz), but should you
choose the largest, smallest, or middle value to be the odd one out?
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
a more precise distance algorithm ravas <ravas@outlook.com> - 2015-05-25 12:21 -0700
Re: a more precise distance algorithm felix <felix@epepm.cupet.cu> - 2015-05-25 16:06 -0400
Re: a more precise distance algorithm Christian Gollwitzer <auriocus@gmx.de> - 2015-05-25 22:27 +0200
Re: a more precise distance algorithm ravas <ravas@outlook.com> - 2015-05-25 14:03 -0700
Re: a more precise distance algorithm Gary Herron <gary.herron@islandtraining.com> - 2015-05-25 13:20 -0700
Re: a more precise distance algorithm ravas <ravas@outlook.com> - 2015-05-25 14:05 -0700
Re: a more precise distance algorithm Steven D'Aprano <steve@pearwood.info> - 2015-05-26 13:11 +1000
Re: a more precise distance algorithm ravas <ravas@outlook.com> - 2015-05-25 21:13 -0700
Re: a more precise distance algorithm Gary Herron <gherron@digipen.edu> - 2015-05-25 22:09 -0700
Re: a more precise distance algorithm ravas <ravas@outlook.com> - 2015-05-25 22:49 -0700
Re: a more precise distance algorithm Christian Gollwitzer <auriocus@gmx.de> - 2015-05-26 07:33 +0200
Re: a more precise distance algorithm Brian Blais <bblais@gmail.com> - 2015-05-27 14:00 -0400
Re: a more precise distance algorithm Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-27 23:03 +0100
Re: a more precise distance algorithm Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-27 23:04 -0400
Re: a more precise distance algorithm Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-25 22:42 -0600
Re: a more precise distance algorithm ravas <ravas@outlook.com> - 2015-05-25 21:59 -0700
Re: a more precise distance algorithm random832@fastmail.us - 2015-05-26 09:40 -0400
Re: a more precise distance algorithm random832@fastmail.us - 2015-05-26 09:51 -0400
Re: a more precise distance algorithm Robin Becker <robin@reportlab.com> - 2015-05-27 14:02 +0100
csiph-web