From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Trigonometric functions in degrees |
Date: | 2016-01-25 02:49:11 |
Message-ID: | CAB7nPqSwDt9HR2KertnBOy2ex-N6cY4zh2X=TT+0nmOZgk-yqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 25, 2016 at 2:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Perhaps we can fix this by rewriting as
>
> float8 numerator = 1.0 - cos(x * RADIANS_PER_DEGREE);
> return 1.0 - (numerator / one_minus_cos_60) / 2.0;
>
> cockatiel's compiler does recognize -fexcess-precision=standard, and
> my understanding of that is that the result put into "numerator" will
> be rounded to double width, so that it should then match
> "one_minus_cos_60".
>
> Another idea would be to change the cache variable to just "cos_60" and
> write "(1.0 - cos_60)" in the denominator --- but then we'd just be hoping
> that the compiler does both subtractions the same way, which doesn't seem
> necessarily guaranteed. Worse, I believe the 8087 has an FCOS instruction
> which might deliver a wider-than-double result, so that maybe the problem
> is not so much with the subtraction as with when rounding of the cos()
> result happens. The code I show above seems more likely to match the
> way one_minus_cos_60 is computed.
(Sorry for showing up after the storm)
The fix is working correctly, using gcc's i686-pc-cygwin on cygwin32
the regression does not show up anymore
after 0034757.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2016-01-25 05:09:06 | Re: Patch: fix lock contention for HASHHDR.mutex |
Previous Message | Haribabu Kommi | 2016-01-25 00:56:09 | Re: Parallel Aggregate |