Re: gamma() and lgamma() functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: gamma() and lgamma() functions
Date
Msg-id 2efc3b61-3ebf-4bff-9d08-32869069ce30@eisentraut.org
Whole thread Raw
In response to gamma() and lgamma() functions  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List 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?




pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Avoid logging enormously large messages
Next
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning