Re: Greatest Common Divisor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Greatest Common Divisor
Date: 2020-01-04 00:34:04
Message-ID: 15876.1578098044@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> writes:
> On 04/01/2020 01:21, Tom Lane wrote:
>> Zero is the "correct" answer for that, isn't it, independently of overflow
>> considerations?

> I would say not.

Oh, right, I was misremembering the identity gcd(a,0) as being 0 not a.
Never mind that then.

> The correct answer is INT_MIN but we've decided a
> negative result is not desirable.

Agreed. On the other hand, we could stave off overflow the same
way we discussed for lcm: make it return int8. We're still stuck
with the special case for INT64_MIN in gcd64 of course, so maybe
that's just inconsistent rather than being worthwhile.

[ thinks for a bit... ] In practice, I imagine few people use gcd on
negative values, so doing weird things with the datatype choices is
probably not better than throwing an error for this case.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2020-01-04 00:38:45 Re: Greatest Common Divisor
Previous Message Vik Fearing 2020-01-04 00:26:48 Re: Greatest Common Divisor