On 04/26/2016 11:26 AM, Tom Lane wrote:
> OK, I've pushed a change along these lines. Peter, would you see whether
> HEAD fixes it for you?
Yeah, it passes now. Nobody touch anything! ;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On 26 April 2016 at 16:26, Tom Lane wrote:
> The next time somebody proposes that we can get exact results out of
> floating-point arithmetic, I'm going to run away screaming.
>
Yeah, I think I will have the same reaction.
Thanks for all your hard work getting this to work.
Regards,
Dean
--
On Tue, Apr 26, 2016 at 11:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 26, 2016 at 11:26 AM, Tom Lane wrote:
>>> The next time somebody proposes that we can get exact results out of
>>> floating-point arithmetic, I'm going to run away screaming.
>
>> And you wonder why I avoid fl
Robert Haas writes:
> On Tue, Apr 26, 2016 at 11:26 AM, Tom Lane wrote:
>> The next time somebody proposes that we can get exact results out of
>> floating-point arithmetic, I'm going to run away screaming.
> And you wonder why I avoid floating point variables like the plague...!
Float variable
On Tue, Apr 26, 2016 at 11:26 AM, Tom Lane wrote:
> The next time somebody proposes that we can get exact results out of
> floating-point arithmetic, I'm going to run away screaming.
And you wonder why I avoid floating point variables like the plague...!
--
Robert Haas
EnterpriseDB: http://www.
Dean Rasheed writes:
> On 26 April 2016 at 04:25, Tom Lane wrote:
>> In short, these tests suggest that we need a coding pattern like
>> this:
>> volatile float8 asin_x = asin(x);
>> return (asin_x / asin_0_5) * 30.0;
> Agreed. That looks like the least hacky way of solving the problem. I
> thin
On 26 April 2016 at 04:25, Tom Lane wrote:
> In short, these tests suggest that we need a coding pattern like
> this:
>
> volatile float8 asin_x = asin(x);
> return (asin_x / asin_0_5) * 30.0;
>
> We could drop the "volatile" by adopting -ffloat-store, but that
> doesn't seem like
I wrote:
> Evidently, asin() is returning an 80-bit result, and that's not
> getting rounded to double width before we divide by asin_0_5.
I found that I could reproduce this type of assembly-code behavior
on dromedary (gcc version 4.2.1) by using -mfpmath=387. That box
doesn't show the visible r
On 04/21/2016 08:18 PM, Tom Lane wrote:
> Hm. This seems to prove that we're not getting exactly 1.0 from
> (asin(x) / asin_0_5) with x = 0.5, but I'm having a hard time guessing
> why that might be so when all the other cases work.
>
> Could you send along the assembler code generated by the com
Peter Eisentraut writes:
> On 04/25/2016 03:09 PM, Tom Lane wrote:
>> I'm going to go ahead and push this, because it seems clearly more robust
>> than what we have. But I'd appreciate a report on whether it fixes your
>> issue.
> 6b1a213bbd6599228b2b67f7552ff7cc378797bf did not fix it.
OK ...
On 04/25/2016 03:09 PM, Tom Lane wrote:
> I'm going to go ahead and push this, because it seems clearly more robust
> than what we have. But I'd appreciate a report on whether it fixes your
> issue.
6b1a213bbd6599228b2b67f7552ff7cc378797bf did not fix it.
Attached is the assembler output (-O0) f
I wrote:
> If that is the answer, then the next question is how we can put more
> roadblocks in the way of compile-time evaluation of asin(0.5). Dean
> suggested that creative use of "volatile" might do it, and I agree
> that that sounds like a promising thing to pursue.
It occurred to me that we
Peter Eisentraut writes:
> On 04/21/2016 08:18 PM, Tom Lane wrote:
>> Could you send along the assembler code generated by the compiler (-S
>> output) for float.c? Maybe that would shed some light. Probably the
>> -O0 version would be easier to read.
> Attached is a smaller test program that pr
Peter Eisentraut writes:
> On 04/19/2016 04:48 PM, Tom Lane wrote:
>> Pushed. Peter, what results do you get from these tests on your
>> problematic machine?
> acosd(x),
> acosd(x) IN (0,60,90,120,180) AS acosd_exact
> FROM (VALUES (-1), (-0.5), (0), (0.5), (1)) AS t(x);
> - x
On 04/19/2016 04:48 PM, Tom Lane wrote:
> Pushed. Peter, what results do you get from these tests on your
> problematic machine?
acosd(x),
acosd(x) IN (0,60,90,120,180) AS acosd_exact
FROM (VALUES (-1), (-0.5), (0), (0.5), (1)) AS t(x);
- x | asind | asind_exact | acosd | acos
Dean Rasheed writes:
> On 19 April 2016 at 14:38, Tom Lane wrote:
>> Yeah, what I was thinking of printing is something like
>>
>> asind(x),
>> asind(x) IN (-90,-30,0,30,90) AS asind_exact,
>> ...
>>
>> with extra_float_digits=3.
> OK, that sounds like it would be a useful improvement to the t
On 19 April 2016 at 14:38, Tom Lane wrote:
> Yeah, what I was thinking of printing is something like
>
> asind(x),
> asind(x) IN (-90,-30,0,30,90) AS asind_exact,
> ...
>
> with extra_float_digits=3. The point of this is not necessarily to give
> any extra information, tho
Dean Rasheed writes:
> On 19 April 2016 at 05:16, Noah Misch wrote:
>> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
>>> Hm? The expected answer is exact (30, 45, or whatever) in each case.
>>> If we get some residual low-order digits then it's a failure, so we don't
>>> need to worr
On 19 April 2016 at 05:16, Noah Misch wrote:
> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
>> >> We could alternatively set extra_float_digits to its max value and hope
>> >> that off-by-one-in-the-
Noah Misch writes:
> On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
>> We could alternatively set extra_float_digits to its max value and hope
>> that off-by-one-in-the-last-place values would get printed as something
>> visibly different from the exact result. I'm not sure I want to t
Noah Misch writes:
> On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote:
>> Given that it's apparently showing the results of asind as NULL ...
> I doubt asind is returning NULL. Here's the query, which uses a CASE to
> report NULL if asind returns any value not on a whitelist:
> SELECT x
21 matches
Mail list logo
