Re: gamma() and lgamma() functions

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: gamma() and lgamma() functions
Date: 2024-08-23 12:40:42
Message-ID: 2efc3b61-3ebf-4bff-9d08-32869069ce30@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01.07.24 12:33, Dean Rasheed wrote:
> Attached is a patch adding support for the gamma and log-gamma
> functions. See, for example:
>
> https://en.wikipedia.org/wiki/Gamma_function
>
> I think these are very useful general-purpose mathematical functions.
> They're part of C99, and they're commonly included in other
> mathematical libraries, such as the python math module, so I think
> it's useful to make them available from SQL.

What are examples of where this would be useful in a database context?

> The error-handling for these functions seems to be a little trickier
> than most, so that might need further discussion.

Yeah, this is quite something.

I'm not sure why you are doing the testing for special values (NaN etc.)
yourself when the C library function already does it. For example, if I
remove the isnan(arg1) check in your dlgamma(), then it still behaves
the same in all tests. However, the same does not happen in your
dgamma(). The overflow checks after the C library call are written
differently for the two functions. dgamma() does not check errno for
ERANGE for example. It might also be good if dgamma() checked errno for
EDOM, because other the result of gamma(-1) being "overflow" seems a bit
wrong.

I'm also not clear why you are turning a genuine result overflow into
infinity in lgamma().

I think this could use some kind of chart or something about all the
possible behaviors and how the C library reports them and what we intend
to do with them.

Btw., I'm reading that lgamma() in the C library is not necessarily
thread-safe. Is that a possible problem?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2024-08-23 12:48:27 Re: generic plans and "initial" pruning
Previous Message Kirill Reshke 2024-08-23 12:36:48 Avoid logging enormously large messages