Re: Add error functions: erf() and erfc() - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Add error functions: erf() and erfc()
Date
Msg-id CAEZATCWHj7sX3jG610LsQu8qFjcoYCtek10BumWNUkvS5ZyV8g@mail.gmail.com
Whole thread Raw
In response to Re: Add error functions: erf() and erfc()  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Add error functions: erf() and erfc()  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Wed, 8 Mar 2023 at 23:24, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> No comment on the maths, but I'm pretty sure we won't need a fallback
> implementation.  That stuff goes back to the math libraries of 80s
> Unixes, even though it didn't make it into C until '99.  I just
> checked the man pages for all our target systems and they all show it.
> (There might be some portability details around the tgmath.h versions
> on some systems, eg to support different float sizes, I dunno, but
> you're using the plain math.h versions.)
>

Thanks for checking. Hopefully they will be available everywhere.

I think what's more likely to happen is that the tests will reveal
implementation variations, as they did when the hyperbolic functions
were added, and it'll be necessary to adjust or remove some of the
test cases. When I originally wrote those tests, I picked a value from
each branch that the FreeBSD implementation handled differently, but I
think that's overkill. If the purpose of the tests is just to confirm
that the right C library function has been exposed, they could
probably be pared all the way down to just testing erf(1) and erfc(1),
but it might be useful to first see what platform variations exist.

> Two related functions that also arrived in C99 are lgamma() and
> tgamma().  If you'll excuse the digression, that reminded me of
> something I was trying to figure out once, for a practical problem.
> My statistics knowledge is extremely patchy, but I have been trying to
> up my benchmarking game, and that led to a bit of remedial reading on
> Student's t tests and related stuff.  A few shaven yaks later, I
> understood that you could probably (if you like pain) do that sort of
> stuff inside PostgreSQL using our existing aggregates, if you took the
> approach of ministat[1].  That tool has a table of critical values
> inside it, indexed by degrees-of-freedom (1-100) and confidence level
> (80, 90, 95, 98, 99, 99.5), and one could probably write SQL queries
> that spit out an answer like "p is less than 5%, ship it!", if we
> stole that table.  But what if I actually want to know p?  Of course
> you can do all that good stuff very easily with tools like R, SciPy
> etc and maybe that's the best way to do it.  But Oracle, and I think
> several other analytics-focused SQL systems, can do it in a very easy
> built-in way.  I think to get at that you probably need the t CDF, and
> in there[2] I see... Γ().  Huh.
>

Hmm, possibly having the gamma function would be independently useful
for other things too. I don't want to get side-tracked though.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
Next
From: Andrey Borodin
Date:
Subject: Re: psql \watch 2nd argument: iteration count