Re: Review: Patch for phypot - Pygmy Hippotause - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Review: Patch for phypot - Pygmy Hippotause
Date
Msg-id AANLkTimc6dk7ILkbnMz0GqgYL-sFu8A22_x_xqzzjMG7@mail.gmail.com
Whole thread Raw
In response to Re: Review: Patch for phypot - Pygmy Hippotause  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Review: Patch for phypot - Pygmy Hippotause
List pgsql-hackers
On 17 July 2010 20:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ...  For instance, if x is 1e8 * y, then y*y
> fails to affect the sum at all (given typical float8 arithmetic), and
> you'll get back sqrt(x*x) even though y should have been able to affect
> the result at the 8th place or so.  In the patch's calculation, y/x is
> computed accurately but then we'll lose the same precision when we form
> 1 + yx*yx --- the result will be just 1 if y is lots smaller than x.
>

No. If x is 1e8 * y, then y will only affect the result in the 16th
place. You can see this if you do a simple series expansion:

sqrt(1+yx^2) = 1 + 1/2 yx^2 + O(yx^4)

> If we were feeling tense about this, we could look for an alternate way
> of calculating sqrt(1 + yx*yx) that doesn't lose so much accuracy.
> In principle I think that's doable since this expression is related to
> ln(1+x) which can be calculated accurately even for very small x.

This algorithm is about as accurate as it could possibly be. The point
with ln(1+x) is that for small x:

ln(1+x) = x + O(x^2)

so you would loose precision if x were much smaller than 1. This is
not the case with sqrt(1+x).

For most cases, the new algorithm is no more accurate than the old
one. The exception is when *both* x and y are very small. In this
case, it protects against incorrect underflows to 0.

Regards,
Dean


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: crash-recovery replay of CREATE TABLESPACE is broken in HEAD
Next
From: Peter Eisentraut
Date:
Subject: Re: standard_conforming_strings