Piotr Stefaniak writes:
> These changes from 65abaab547a5758b0d6d92df4af1663bb47d545f
> - result = sign * cosd_q1(arg1) / sind_q1(arg1);
> + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45);
> and
> - result = sign * sind_q1(arg1) / cosd_q1(arg1);
> + result = sign * ((sind_q1(arg1) /
On 01/31/2016 01:23 PM, Michael Paquier wrote:
Per IEEE 754, division by 0 for a double results in Nan or +/-Inf, so
that's actually correct.
I didn't know that. I guess that in practice that is OK and the case is
closed.
Interestingly to me, that assumption appears to rely on the C
impleme
On Sun, Jan 31, 2016 at 9:01 PM, Piotr Stefaniak
wrote:
> - result = sign * cosd_q1(arg1) / sind_q1(arg1);
> + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45);
>
> and
>
> - result = sign * sind_q1(arg1) / cosd_q1(arg1);
> + result = sign * ((sind_q1(arg1) / cosd_q1(arg1)) / tan_45);
>
These changes from 65abaab547a5758b0d6d92df4af1663bb47d545f
- result = sign * cosd_q1(arg1) / sind_q1(arg1);
+ result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45);
and
- result = sign * sind_q1(arg1) / cosd_q1(arg1);
+ result = sign * ((sind_q1(arg1) / cosd_q1(arg1)) / tan_45);
both int
On Mon, Jan 25, 2016 at 2:34 AM, Tom Lane 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 understand
On 1/23/16 4:18 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 1/23/16 3:05 PM, Tom Lane wrote:
>>> Peter Eisentraut writes:
I'm still getting a failure in float8 on OS X after commit 73193d8:
>
>>> Weird, because my OS X critters are all happy. Which OS X and compiler
>>> version, e
Dean Rasheed writes:
> If I understand correctly there were 2 separate issues at play here:
> 1). On some platforms the compiler evaluates expressions like
> sin(constant) and comes up with a slightly different result than a
> runtime evaluation of the expression. The compiler-evaluated result
>
On 23 January 2016 at 23:04, Tom Lane wrote:
> Noah Misch writes:
>> On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote:
>>> Either I missed something or there's another issue, because tern/sungazer
>>> are *still* failing. This is getting annoying :-(
>
>> sungazer's "make check" passes i
Noah Misch writes:
> On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote:
>> Either I missed something or there's another issue, because tern/sungazer
>> are *still* failing. This is getting annoying :-(
> sungazer's "make check" passes if I change init_degree_constants() to be
> non-static
On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > To reliably produce exact answers, this code must delay all trigonometric
> > calculations to runtime. On sungazer, the float8 test happens to pass if I
> > rebuild float.c with -fno-builtin-sin; that leaves calls
Noah Misch writes:
> To reliably produce exact answers, this code must delay all trigonometric
> calculations to runtime. On sungazer, the float8 test happens to pass if I
> rebuild float.c with -fno-builtin-sin; that leaves calls like acos(0.5) and
> cos(60.0 * RADIANS_PER_DEGREE) unprotected, t
Peter Eisentraut writes:
> On 1/23/16 3:05 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> I'm still getting a failure in float8 on OS X after commit 73193d8:
>> Weird, because my OS X critters are all happy. Which OS X and compiler
>> version, exactly? Any special compile flags?
> I'm us
On 1/23/16 3:05 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 1/23/16 12:08 PM, Tom Lane wrote:
>>> So I pushed that, and tern/sungazer are still failing. Noah, could you
>>> trace through that and see exactly where it's going off the rails?
>
>> I'm still getting a failure in float8 on O
Noah Misch writes:
> On Sat, Jan 23, 2016 at 12:08:40PM -0500, Tom Lane wrote:
>> So I pushed that, and tern/sungazer are still failing. Noah, could you
>> trace through that and see exactly where it's going off the rails?
> The second sin() is a constant, so gcc computes it immediately but send
On Sat, Jan 23, 2016 at 12:08:40PM -0500, Tom Lane wrote:
> I wrote:
> > So the early returns from the buildfarm aren't very good:
> > * tern/sungazer isn't getting exactly 0.5 from sind(30).
>
> > The tern/sungazer result implies that this:
>
> > return (sin(x * (M_PI / 180.0)) / sin(30.0 *
Peter Eisentraut writes:
> On 1/23/16 12:08 PM, Tom Lane wrote:
>> So I pushed that, and tern/sungazer are still failing. Noah, could you
>> trace through that and see exactly where it's going off the rails?
> I'm still getting a failure in float8 on OS X after commit 73193d8:
Weird, because my
On 1/23/16 12:08 PM, Tom Lane wrote:
> So I pushed that, and tern/sungazer are still failing. Noah, could you
> trace through that and see exactly where it's going off the rails?
I'm still getting a failure in float8 on OS X after commit 73193d8:
@@ -490,9 +490,9 @@
x | asind | acosd | atan
I wrote:
> So the early returns from the buildfarm aren't very good:
> * tern/sungazer isn't getting exactly 0.5 from sind(30).
> The tern/sungazer result implies that this:
> return (sin(x * (M_PI / 180.0)) / sin(30.0 * (M_PI / 180.0))) / 2.0;
> is not producing exactly 0.5, which means t
I wrote:
> Dean Rasheed writes:
>> Attached are patches for this and the new functions in degrees, now
>> with POSIX compatible Inf/NaN handling.
> Pushed with minor, mostly cosmetic fixes.
So the early returns from the buildfarm aren't very good:
* tern/sungazer isn't getting exactly 0.5 from
Dean Rasheed writes:
> I tried using feclearexcept + fetestexcept as recommended by
> POSIX.1-2008, and that does indeed make the above examples compliant
> on my linux box. Unfortunately it introduces new errors -- asin starts
> generating FE_UNDERFLOW errors for numbers that are really not that
On 19 January 2016 at 06:32, Michael Paquier wrote:
> The first patch looks fine to me, a nitpick:
> + /* Be sure to throw an error if the input is infinite --- see dcos */
> s/dcos/docs
>
No, I meant dcos the function there. I would normally write that as
dcos() to indicate that it is a fu
On Mon, Jan 18, 2016 at 5:01 AM, Dean Rasheed wrote:
> On 30 November 2015 at 14:11, Tom Lane wrote:
>> FWIW, I think that probably the best course of action is to go ahead
>> and install POSIX-compliant error checking in the existing functions
>> too. POSIX:2008 is quite clear about this:
>>
>>
On 30 November 2015 at 14:11, Tom Lane wrote:
> FWIW, I think that probably the best course of action is to go ahead
> and install POSIX-compliant error checking in the existing functions
> too. POSIX:2008 is quite clear about this:
>
> : An application wishing to check for error situations shoul
On Wed, Dec 2, 2015 at 3:30 AM, Dean Rasheed wrote:
> On 1 December 2015 at 12:59, Michael Paquier
> wrote:
>> Dean, are you planning to continue working on this patch? If yes, are
>> you fine to move it to next CF? It seems that the current consensus is
>> to split this effort into two patches:
On 1 December 2015 at 12:59, Michael Paquier wrote:
> Dean, are you planning to continue working on this patch? If yes, are
> you fine to move it to next CF? It seems that the current consensus is
> to split this effort into two patches:
Yes, I still plan to work on it. I might not get much time
On Mon, Nov 30, 2015 at 11:24 PM, Michael Paquier
wrote:
> On Mon, Nov 30, 2015 at 11:11 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote:
Instinctively, it seems to me that we had better return Nan for the
new asind and acosd w
On Mon, Nov 30, 2015 at 11:11 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote:
>>> Instinctively, it seems to me that we had better return Nan for the
>>> new asind and acosd when being out of range for OSX, Linux will
>>> complain about an
Michael Paquier writes:
> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote:
>> Instinctively, it seems to me that we had better return Nan for the
>> new asind and acosd when being out of range for OSX, Linux will
>> complain about an out-of-range error so the code is right in this
>> case.
On Mon, Nov 30, 2015 at 10:39 PM, Michael Paquier
wrote:
> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote:
>> Instinctively, it seems to me that we had better return Nan for the
>> new asind and acosd when being out of range for OSX, Linux will
>> complain about an out-of-range error so t
On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote:
> Instinctively, it seems to me that we had better return Nan for the
> new asind and acosd when being out of range for OSX, Linux will
> complain about an out-of-range error so the code is right in this
> case.
This is still mentioned upthr
On Fri, Nov 27, 2015 at 6:33 PM, Dean Rasheed wrote:
>
> On 11 November 2015 at 11:45, Dean Rasheed wrote:
> > Thanks for testing. I'll post an updated patch sometime soon.
> >
>
> I finally got round to looking at this again, and here is an updated patch.
Cool, thanks!
> I've reverted the chan
On 11 November 2015 at 11:45, Dean Rasheed wrote:
> Thanks for testing. I'll post an updated patch sometime soon.
>
I finally got round to looking at this again, and here is an updated patch.
I've reverted the changes to the CHECKFLOATVAL() checks in the
existing functions, so that can be a sepa
On 11 November 2015 at 06:04, Michael Paquier wrote:
>>> I also modified some of the CHECKFLOATVAL() checks which didn't look
>>> right to me, unless there's some odd platform-specific behaviour that
>>> I'm not aware of, functions like sin and asin should never return
>>> infinity.
>
> - CH
On Tue, Nov 10, 2015 at 11:17 PM, Michael Paquier
wrote:
> On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed
wrote:
>> On 27 October 2015 at 08:24, Dean Rasheed
wrote:
>>> I think it's still feasible to have sind(30) = 0.5 exactly and keep
>>> monotonicity
>>>
>>
>> Here's a patch along those lin
On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed wrote:
> On 27 October 2015 at 08:24, Dean Rasheed wrote:
>> I think it's still feasible to have sind(30) = 0.5 exactly and keep
>> monotonicity
>>
>
> Here's a patch along those lines. It turned out to be fairly
> straightforward. It's still basic
On 27 October 2015 at 08:24, Dean Rasheed wrote:
> I think it's still feasible to have sind(30) = 0.5 exactly and keep
> monotonicity
>
Here's a patch along those lines. It turned out to be fairly
straightforward. It's still basically a thin wrapper on top of the
math library trig functions,
On 26 October 2015 at 22:51, Tom Lane wrote:
> Dean Rasheed writes:
>> Personally I'd rather have sind(30) be exactly 0.5, even if
>> sind(29.999...) or sind(30.000...1) ended up the wrong side of it.
>
> TBH, sir, if you think that you are too dangerous to be allowed anywhere
> near any numerica
Dean Rasheed writes:
> Personally I'd rather have sind(30) be exactly 0.5, even if
> sind(29.999...) or sind(30.000...1) ended up the wrong side of it.
TBH, sir, if you think that you are too dangerous to be allowed anywhere
near any numerical analysis code. Preserving mathematical properties li
On 10/26/15 1:48 PM, Simon Riggs wrote:
Deviation from SI units is no laughing matter. How would we even know
how to capitalise "Fortnight"?
It's all fun and games until someone pokes Mars' eye out with a spacecraft.
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
(Ok, I guess we just spra
>
>
>
Stupid question - is sin(3m) a call-through to the math coprocessor? It
probably only matters when doing a series of calculations (where the extra
guard bits can matter) and not when doing a simple one-time lookup but it
might be something to consider in regards to setting a precedent.
B
On 26 October 2015 at 20:19, Tom Lane wrote:
> Dean Rasheed writes:
>> I'm thinking something along the lines of:
>
>> 1. Reduce the range of the input (say to 0..90 degrees).
>> 2. Handle special cases (0, 30 and 90 for sind()).
>> 3. Otherwise convert to radians for the general case.
>
> I'd be
Dean Rasheed writes:
> On 26 October 2015 at 19:45, Peter Eisentraut wrote:
>> But how you are going to implement that? I don't see a sind() in the C
>> library.
> I'm thinking something along the lines of:
> 1. Reduce the range of the input (say to 0..90 degrees).
> 2. Handle special cases (0
On 26 October 2015 at 19:45, Peter Eisentraut wrote:
> On 10/24/15 5:24 AM, Dean Rasheed wrote:
>> Additionally, functions that worked natively in degrees would be able
>> to return exact answers in special cases like cosd(90) = 0, whereas
>> cos(radians(90)) is not exactly 0 because pi/2 cannot b
On 10/24/15 5:24 AM, Dean Rasheed wrote:
> Additionally, functions that worked natively in degrees would be able
> to return exact answers in special cases like cosd(90) = 0, whereas
> cos(radians(90)) is not exactly 0 because pi/2 cannot be represented
> exactly as a floating point number.
But ho
On 26 October 2015 at 18:58, Tom Lane wrote:
> Dean Rasheed writes:
>> On 26 October 2015 at 14:18, Tom Lane wrote:
>>> ... but having said that, your argument here is faulty, because 0.9
>>> in itself is not exactly representable in binary. You'd be relying
>>> on roundoff happening in the rig
Dean Rasheed writes:
> On 26 October 2015 at 14:18, Tom Lane wrote:
>> ... but having said that, your argument here is faulty, because 0.9
>> in itself is not exactly representable in binary. You'd be relying
>> on roundoff happening in the right direction to get exact answers
>> from such calcu
On 26 October 2015 at 13:58, Robert Haas wrote:
> > Also -1 to furlongs, fortnights, pecks and hundredweight, amongst others.
>
> Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be
> cool.
>
Deviation from SI units is no laughing matter. How would we even know how
to capit
On 26 October 2015 at 14:18, Tom Lane wrote:
>> Having degree-based functions would make it trivial to implement
>> user-defined gradian-based functions, just by multiplying or dividing
>> by 0.9, and they would return exact results in the smaller number of
>> cases where gradian results are exact
On Mon, Oct 26, 2015 at 1:29 PM, Simon Riggs wrote:
> On 26 October 2015 at 10:18, Tom Lane wrote:
>> Dean Rasheed writes:
>> > On 25 October 2015 at 09:16, Emre Hasegeli wrote:
>> >> I would prefer gradian over degree.
>>
>> > I think gradians are generally less commonly used than degrees and
On 26 October 2015 at 10:18, Tom Lane wrote:
> Dean Rasheed writes:
> > On 25 October 2015 at 09:16, Emre Hasegeli wrote:
> >> I would prefer gradian over degree.
>
> > I think gradians are generally less commonly used than degrees and
> > radians, so I'm less inclined to include them.
>
> I ag
Dean Rasheed writes:
> On 25 October 2015 at 09:16, Emre Hasegeli wrote:
>> I would prefer gradian over degree.
> I think gradians are generally less commonly used than degrees and
> radians, so I'm less inclined to include them.
I agree. gradians are not often used at all, AFAICT.
> Having d
On 25 October 2015 at 09:16, Emre Hasegeli wrote:
>> Currently PostgreSQL only has trigonometric functions that work in
>> radians. I think it would be quite useful to have an equivalent set of
>> functions that worked in degrees. In other environments these are
>> commonly spelled sind(), cosd(),
On Sun, Oct 25, 2015 at 10:16:41AM +0100, Emre Hasegeli wrote:
> > Currently PostgreSQL only has trigonometric functions that work in
> > radians. I think it would be quite useful to have an equivalent set of
> > functions that worked in degrees. In other environments these are
> > commonly spelled
On Sun, Oct 25, 2015 at 6:16 PM, Emre Hasegeli wrote:
>> Currently PostgreSQL only has trigonometric functions that work in
>> radians. I think it would be quite useful to have an equivalent set of
>> functions that worked in degrees. In other environments these are
>> commonly spelled sind(), cos
> Currently PostgreSQL only has trigonometric functions that work in
> radians. I think it would be quite useful to have an equivalent set of
> functions that worked in degrees. In other environments these are
> commonly spelled sind(), cosd(), etc.
I would prefer gradian over degree.
--
Sent v
On 24 October 2015 at 05:24, Dean Rasheed wrote:
> Currently PostgreSQL only has trigonometric functions that work in
> radians. I think it would be quite useful to have an equivalent set of
> functions that worked in degrees. In other environments these are
> commonly spelled sind(), cosd(), etc
56 matches
Mail list logo
