Re: gamma() and lgamma() functions

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: gamma() and lgamma() functions
Date: 2025-03-02 10:29:59
Message-ID: CAEZATCWm7NdTiCN9CbaVEkgcEb0UT7enxnxwck5BHvVR28658g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 14 Nov 2024 at 22:35, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> On Thu, 14 Nov 2024 at 16:28, Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> wrote:
> >
> > >SELECT gamma(float8 '1e-320');
> > ERROR: value out of range: overflow
> >
> > >SELECT gamma(float8 '0');
> > gamma
> > ----------
> > Infinity
> > (1 row)
> >
> > Perhaps it would be logical if the behavior in these cases was the same
> > (either ERROR or 'Infinity')?
>
> In general, I think that having gamma() throw overflow errors is
> useful for spotting real problems in user code.
>

Thinking about this afresh, I remain of the opinion that having the
gamma function throw overflow errors is useful for inputs that are too
large, like gamma(200). But then, if we're going to do that, maybe we
should just do the same for other invalid inputs (zero, negative
integers, and -Inf). That resolves the consistency issue with inputs
very close to zero, and seems like a practical solution.

Attached is an update doing that.

Regards,
Dean

Attachment Content-Type Size
v5-0001-Add-support-for-gamma-and-lgamma-functions.patch text/x-patch 9.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Friedman 2025-03-02 10:42:17 Re: Doc: clarify possibility of ephemeral discrepancies between state and wait_event in pg_stat_activity
Previous Message jian he 2025-03-02 09:50:50 Re: bug when apply fast default mechanism for adding new column over domain with default value