Implementation of half-cycle trignometric functions
Steve Kargl
sgk at troutmask.apl.washington.edu
Thu May 18 23:47:30 UTC 2017
On Fri, May 19, 2017 at 08:56:27AM +1000, Bruce Evans wrote:
> On Thu, 18 May 2017, Steve Kargl wrote:
>
> > On Thu, May 18, 2017 at 04:34:57PM +1000, Bruce Evans wrote:
> >> On Wed, 17 May 2017, Steve Kargl wrote:
> >>
> >>> On Thu, May 18, 2017 at 09:25:58AM +1000, Bruce Evans wrote:
> >>>> On Wed, 17 May 2017, Steve Kargl wrote:
> >>> ...
> >>>>> 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.
> >>
> >> ld128 has precision 113.
> >
> > Yes. I know.
> >
> >>> 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
> >>
> >> But hi is set intentionally sloppily by converting to double, so it has
> >> 53 bits instead of the 57 that 56 would go with (57 = 113/2 rounded up).
> >
> > A 53-bit entity times a 56-bit entity needs 109-bits for the result.
> > A 113-bit entity can hold a 109-bit entity. Or am I missing something?
>
> It wastes 4 bits. This reader has to guess if this is intentional for
> magic elsewhere, or just sloppy.
>
> Also, the rounded value might naturally have some extra low zero bits.
> So looking at the bits, it is not easy to see if there are the right
> number. This is not worth a comment. The reader should trust that
> the right (maximal) number of bits are used, and only check it
> approximately.
Unfortunately, I don't have the capibility to easily convert
an ld128 number to hex; otherwise, I would include a comment
with the hex representation.
> The double precision pi*hi and pi*lo also seemed to be sloppily
> rounded. My version has less precision (28 low zero bits in pi_hi
> instead of the minimal 24), while yours has 27 low zero bits in
> pihi. The explanation for this is something like:
> - I copied pi_hi from another file with slightly different requirements
> - the choice makes pi_lo positive but pilo negative. The other file
> might have need pi_lo positive, or just extra zero bits in pi_hi.
> Most likely just the latter.
> - your 27 is apparently from the calculation 53 - 53 / 2 for almost
> even splitting of x, but the splitting of x is uneven (24 + 29).
The last one is the closest. I did p/2+1. Yes, the splitting for
x is too sloppy.
--
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