small cleanup patch for e_pow.c

Steve Kargl sgk at troutmask.apl.washington.edu
Sun May 10 20:59:48 UTC 2015


On Mon, May 11, 2015 at 06:36:51AM +1000, Bruce Evans wrote:
> On Sun, 10 May 2015, Steve Kargl wrote:
> 
> > On Sun, May 10, 2015 at 08:16:14PM +1000, Bruce Evans wrote:
> >> ...
> >> So 1 is the only numbers near 1 that doesn't give overflow.
> >
> > Thanks for the explanation!  That help dislodge a mental block.
> >
> > To find the magic numbers, it seems I need to consider
> >
> > (1-2**(-p))**(2**N) = 2**(emin-p)          for underflow
> > (1+2**(-p))**(2**N) = (1-2**(-p))*2**emax  for overflow
> >
> > With p = [24, 53, 64, 113], emin = [-125, -1021, -16381, -16381],
> > emax = [128, 1024, 16384, 16384], and the use of log(1+z) = z for
> > |z| << 1, I find
> >
> > underflow:  N = [30.7, 62.5, 77.5, 126.5]
> > overflow:   N = [30.5, 62.5, 77.5, 126.5]
> 
> I plugged some numbers into pari to get sloppy estimates.  E.g.,
> (1 + 2^-23.0)^(2^N) / 2^128; then bump up N until the result is > 1.
> I get this at N = 29.5, so 30.7 seems too high.
> 

I used p = 24 in my (1+-2^(-p)).  It seems that you're using p-1=23.

(1-2**(-p))**(2**N) = 2**(emin-p)

Using log() and log(1+z) = z for |z| << 1, the above equation gives

N = p + log((p-emin) * log(2)) / log(2)

where the equality is of course approximation.

p = 24 --> N = 30.690
p = 23 --> N = 29.681

-- 
Steve


More information about the freebsd-numerics mailing list