Andrew Dunstan writes:
> On 3/14/19 3:08 PM, Tom Lane wrote:
>> I feel therefore that what we should do (barring new evidence) is either
>> 1. Remove all the inf/nan test cases for the hyoerbolic functions ...
>> 2. Just comment out the one failing test, with a note about why.
> 2. would help us
On 3/14/19 3:08 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/14/19 12:41 AM, Tom Lane wrote:
>>> So far, no other failures ...
>> I have replicated this on my Msys2 test system.
>> I assume it's a bug in the mingw math library. I think jacana is the
>> only currently reporting mingw
Andrew Dunstan writes:
> On 3/14/19 12:41 AM, Tom Lane wrote:
>> So far, no other failures ...
> I have replicated this on my Msys2 test system.
> I assume it's a bug in the mingw math library. I think jacana is the
> only currently reporting mingw member :-( The MSVC members appear to be
>
On 3/14/19 12:41 AM, Tom Lane wrote:
> Dean Rasheed writes:
>> I'm amazed that jacana's asinh() returned -0 for an input of +0.
> Even more amusingly, it returns NaN for acosh('infinity'), cf
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana=2019-03-14%2003%3A00%3A34
>
>
On Thu, 14 Mar 2019 at 04:41, Tom Lane wrote:
>
> Dean Rasheed writes:
> > I'm amazed that jacana's asinh() returned -0 for an input of +0.
>
> Even more amusingly, it returns NaN for acosh('infinity'), cf
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana=2019-03-14%2003%3A00%3A34
Dean Rasheed writes:
> I'm amazed that jacana's asinh() returned -0 for an input of +0.
Even more amusingly, it returns NaN for acosh('infinity'), cf
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana=2019-03-14%2003%3A00%3A34
Presumably that means they calculated "infinity -
At Wed, 13 Mar 2019 23:18:27 -0400, Tom Lane wrote in
<2503.1552533...@sss.pgh.pa.us>
tgl> Andrew Dunstan writes:
tgl> > Or we could possibly call the function and then turn a result of -0 into
0?
tgl>
tgl> But -0 is the correct output if the input is -0. So that approach
tgl> requires
Andrew Dunstan writes:
> Or we could possibly call the function and then turn a result of -0 into 0?
But -0 is the correct output if the input is -0. So that approach
requires distinguishing -0 from 0, which is annoyingly difficult.
regards, tom lane
On 3/13/19 5:56 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Mar 12, 2019 at 11:16:42PM -0400, Tom Lane wrote:
>>> I'm inclined to leave it as-is for a day or so and see if any
>>> other failures turn up, before deciding what to do about it.
>> Fine by me.
> Well, so far jacana is
Robert Haas writes:
> On Wed, Mar 13, 2019 at 10:39 PM Tom Lane wrote:
>> No, but that's not the hazard. I have a very fresh-in-mind example:
>> at one point while tweaking Laetitia's patch, I'd accidentally changed
>> datanh so that it called tanh not atanh. The previous set of tests did
>>
On Wed, Mar 13, 2019 at 10:39 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Mar 13, 2019 at 8:49 PM Tom Lane wrote:
> >> Meh. As I said before, we're not in the business of improving on what
> >> libm does --- if someone has a beef with the results, they need to take
> >> it to their
Robert Haas writes:
> On Wed, Mar 13, 2019 at 8:49 PM Tom Lane wrote:
>> Meh. As I said before, we're not in the business of improving on what
>> libm does --- if someone has a beef with the results, they need to take
>> it to their platform's libm maintainer, not us. The point of testing
>>
On Wed, Mar 13, 2019 at 8:49 PM Tom Lane wrote:
> Meh. As I said before, we're not in the business of improving on what
> libm does --- if someone has a beef with the results, they need to take
> it to their platform's libm maintainer, not us. The point of testing
> this at all is just to
Dean Rasheed writes:
> It's not unreasonable to expect these functions to be accurate to within
> the last 1 or 2 digits, so testing with extra_float_digits or whatever
> seems reasonable, but I think a wider variety of test inputs is required.
Meh. As I said before, we're not in the business
On Wed, 13 Mar 2019, 21:56 Tom Lane, wrote:
>
> Of these, probably the least bad is #3, even though it might require
> a few rounds of experimentation to find the best extra_float_digits
> setting to use. I'll go try it without any roundoff, just to see
> what the raw results look like ...
>
Michael Paquier writes:
> On Tue, Mar 12, 2019 at 11:16:42PM -0400, Tom Lane wrote:
>> I'm inclined to leave it as-is for a day or so and see if any
>> other failures turn up, before deciding what to do about it.
> Fine by me.
Well, so far jacana is the only critter that's shown any problem.
I
On Tue, Mar 12, 2019 at 11:16:42PM -0400, Tom Lane wrote:
> Yeah. I warned Laetitia about not testing corner cases, but
> it hadn't occurred to me that zero might be a corner case :-(
I was honestly expecting more failures than that when I saw the patch
landing. This stuff is tricky :)
> I'm
Michael Paquier writes:
> On Tue, Mar 12, 2019 at 07:55:14PM +, Tom Lane wrote:
>> Add support for hyperbolic functions, as well as log10().
> jacana is not a fan of this commit, and failed on float8:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana=2019-03-13%2000%3A00%3A27
On Tue, Mar 12, 2019 at 07:55:14PM +, Tom Lane wrote:
> Add support for hyperbolic functions, as well as log10().
>
> The SQL:2016 standard adds support for the hyperbolic functions
> sinh(), cosh(), and tanh(). POSIX has long required libm to
> provide those functions as well as their
19 matches
Mail list logo
