On Mon, 1 Jul 2024 at 16:04, Alvaro Herrera <alvhe...@alvh.no-ip.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
