Re: gamma() and lgamma() functions

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Fri, 23 Aug 2024 at 13:40, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> What are examples of where this would be useful in a database context?

> Of course, there's a somewhat fuzzy line between what is generally
> useful enough, and what is too specialised for core Postgres, but I
> would argue that these qualify, since they are part of C99, and
> commonly appear in other general-purpose math libraries like the
> Python math module.

Yeah, I think any math function that's part of C99 or POSIX is
arguably of general interest.

>> 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.

> It's useful to do that so that we don't need to assume that every
> platform conforms to the POSIX standard, and because it simplifies the
> later overflow checks. This is consistent with the approach taken in
> other functions, such as dexp(), dsin(), dcos(), etc.

dexp() and those other functions date from the late stone age, before
it was safe to assume that libm's behavior matched the POSIX specs.
Today I think we can assume that, at least till proven differently.
There's not necessarily anything wrong with what you've coded, but
I don't buy this argument for it.

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

> It's not quite clear what to do about that.

Per the Linux man page, the reason lgamma() isn't thread-safe is

The lgamma(), lgammaf(), and lgammal() functions return the natural
logarithm of the absolute value of the Gamma function. The sign of the
Gamma function is returned in the external integer signgam declared in
<math.h>. It is 1 when the Gamma function is positive or zero, -1 when
it is negative.

AFAICS this patch doesn't inspect signgam, so whether it gets
overwritten by a concurrent thread wouldn't matter. However,
it'd be a good idea to add a comment noting the hazard.

(Presumably, the reason POSIX says "need not be thread-safe"
is that an implementation could make it thread-safe by
making signgam thread-local, but the standard doesn't wish
to mandate that.)

regards, tom lane