Re: Infinity vs Error for division by zero

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Matt Pulver <mpulver(at)unitytechgroup(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Infinity vs Error for division by zero
Date: 2019-03-01 19:26:13
Message-ID: CAKFQuwYMupdizqDihYjr+rfn4s6MUn6coB4JRw6iJTe2D2yDiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, March 1, 2019, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:

>
> But if someone wanted to write a user-defined division function or
> operator that would return Inf for (anything > 0) / 0 and for
> (anything < 0) / -0, and -Inf for (anything < 0) / 0 and for
> (anything > 0) / -0, and NaN for (either zero) / (either zero), I think
> that function or operator would be fully in keeping with IEEE 754.
>

Upon further reading you are correct - IEEE 754 has chosen to treat n/0
differently for n=0 and n<>0 cases. I'm sure they have their reasons but
within the scope of this database, and the core arithmetic functions it
provides, those distinctions don't seeming meaningful and having to add
query logic to deal with both cases would just be annoying. I don't use,
or have time for the distraction, to understand why such a decision was
made and how it could be useful. Going from an exception to NaN makes
sense to me, going instead to infinity - outside of limit expressions which
aren't applicable here - does not.

For my part in the queries I have that encounter divide-by-zero I end up
transforming the result to zero which is considerably easier to
present/absorb along side other valid fractions in a table or chart.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2019-03-01 19:26:44 Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Andres Freund 2019-03-01 19:21:24 Re: reloption to prevent VACUUM from truncating empty pages at the end of relation