Re: gamma() and lgamma() functions

On Mon, 1 Jul 2024 at 16:04, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2024-Jul-01, Stepan Neretin wrote:
>
> > I have one notice:
> > ERROR: value out of range: overflow. I think we need to add information
> > about the available ranges in the error message
>
> I think this is a project of its own. The error comes from calling
> float_overflow_error(), which is a generic routine used in several
> functions which have different overflow conditions. It's not clear to
> me that throwing errors listing the specific range for each case is
> worth the effort.
>

Right. It's also worth noting that gamma() has several distinct ranges
of validity for which it doesn't overflow, so it'd be hard to codify
that succinctly in an error message.

Something that bothers me about float.c is that there is precious
little consistency as to whether functions raise overflow errors or
return infinity. For example, exp() gives an overflow error for
sufficiently large (finite) inputs, whereas sinh() and cosh() (very
closely related) return infinity. I think raising an error is the more
technically correct thing to do, but returning infinity is sometimes
perhaps more practically useful.

However, given how much more quickly the result from gamma() explodes,
I think it's more useful for it to raise an error so that you know you
have a problem, and that you probably want to use lgamma() instead.

(As an aside, I've seen people (and ChatGPT) write algorithms to solve
the Birthday Problem using the gamma() function. That doesn't work
because gamma(366) overflows, so you have to use lgamma().)

Regards,
Dean