Re: Greatest Common Divisor

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Greatest Common Divisor
Date: 2019-12-29 17:13:32
Message-ID: alpine.DEB.2.21.1912291755510.14206@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello,

>> Because I do not trust C modulo as I had a lot of problems with it?:-)
>
> If I recall correctly (and I'm traveling and away from those notes),
> the exact semantics of C's % with negative operands was left
> implementation-defined until, was it, C99 ?

Indeed, my woes with C % started before that date:-)

By Googling the C99 spec, I found: "When integers are divided, the result
of the / operator is the algebraic quotient with any fractional part
discarded (aka truncation toward zero). If the quotient a/b is
representable, the expression (a/b)*b + a%b shall equal a."

Let a = 2 and b = -3, then a/b == 0 (-0.666 truncated toward zero), then

(a/b)*b + a%b == a

=> 0 * -3 + (2 % -3) == 2

=> 2 % -3 == 2

Then with a = -2, b = 3, then a/b == 0 (same as above), and the same
reasoning leads to

-2 % 3 == -2

Which is indeed what was produced with C, but not with Python.

The good news is that the absolute value of the modulo is the module in
the usual sense, which is what is needed for the Euclidian descent and
allows fixing the sign afterwards, as Vik was doing.

> So it might be ok to rely on the specified C99 behavior (whichever
> behavior that is, he wrote, notelessly) for PG 12 and later, where
> C99 is expected.

Yep, probably with a comment.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-29 17:13:42 Re: TAP testing for psql's tab completion code
Previous Message Chapman Flack 2019-12-29 16:50:15 Re: Greatest Common Divisor