Dean Rasheed <dean.a.rash...@gmail.com> writes: > On Fri, 23 Aug 2024 at 13:40, Peter Eisentraut <pe...@eisentraut.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