Implementation of half-cycle trignometric functions
Steve Kargl
sgk at troutmask.apl.washington.edu
Thu May 18 01:42:28 UTC 2017
On Thu, May 18, 2017 at 09:25:58AM +1000, Bruce Evans wrote:
> On Wed, 17 May 2017, Steve Kargl wrote:
>
> > On Wed, May 17, 2017 at 12:49:45PM +1000, Bruce Evans wrote:
> >> On Tue, 16 May 2017, Steve Kargl wrote:
> >>
> >>> Index: lib/msun/ld128/s_cospil.c
> >>> ...
> >>> +static const long double
> >>> +pihi = 3.14159265358979322702026593105983920e+00L,
> >>> +pilo = 1.14423774522196636802434264184180742e-17L;
> >>
> >> These are not in normal format, and are hard to read. I can't see if
> >> pihi has the correct number of zero bits for exact multiplication.
> >
> > I don't have access to an ld128 system with suitable
> > facilities to allow me to spit out the hex representation.
>
> flame is still in the freebsd cluster, but is almost unusable because
> its files are an old copy of actual home directories on freefall.
Yes, I know flame is still available. I deleted all infrastructure
I had on freefall over 2 years agos. Need at a minimum GMP and
MPFR.
> Utilities for printing hex and FP in good formats are remarkably rare.
> pari/gp supports many special math types but can only input or output
> ordinarly numbers in decimal. I use my library routines to print hex
> and special FP formats for it. sh, printf(1) and awk(1) are limited
> by native tyoes and have many other defects.
I wrote my own utility with the catchy name hex.
> > As such, I've added a comment
> >
> > /*
> > * pi_hi contains the leading 56 bits of a 169 bit approximation for pi.
> > */
>
> Why 56? 53 + 56 = 109.
This is ld128.
static const long double
pi_hi = 3.14159265358979322702026593105983920e+00L,
pi_lo = 1.14423774522196636802434264184180742e-17L;
pi_hi has 113/2 = 56 bits.
pi_lo has 113 bit.
56 + 113 = 169
>
> >> These don't have the normal spelling. fdlibm never uses pihi or pio2hi,
> >> or pi_hi. It often uses pio2_hi and other pio2_*. My s_sinpi.c uses
> >> pi_hi.
I've changed my spelling.
>
> My improvements to lgamma()'s sin_pi*() are buggy. I forgot the original
> target of avoiding inexact better:
I'll need to wait until the weekend to study your improved sin_pi.
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
More information about the freebsd-numerics
mailing list