Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ilcBe-0006Xx-HT for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Dec 2019 17:17:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ilcBd-00054C-Bf for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Dec 2019 17:17:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ilc8a-0000vo-D4 for pgsql-hackers@lists.postgresql.org; Sun, 29 Dec 2019 17:13:56 +0000 Received: from courriel.mines-paristech.fr ([77.158.173.149] helo=antispam-1.ensmp.fr) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ilc8J-0000d8-0f for pgsql-hackers@lists.postgresql.org; Sun, 29 Dec 2019 17:13:45 +0000 Received: from smtp-4.mines-paristech.fr (smtp-4.ensmp.fr [77.158.173.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by antispam-1.ensmp.fr (antispam.mines-paristech.fr) with ESMTPS id 1E45D56FA6; Sun, 29 Dec 2019 18:13:35 +0100 (CET) Received: from pseudo (53.237.219.88.rev.sfr.net [88.219.237.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-4.mines-paristech.fr (Postfix) with ESMTPSA id 3CCAB2C01EC; Sun, 29 Dec 2019 18:13:34 +0100 (CET) Date: Sun, 29 Dec 2019 18:13:32 +0100 (CET) From: Fabien COELHO X-X-Sender: fabien@pseudo To: Chapman Flack cc: Vik Fearing , PostgreSQL Hackers Subject: Re: Greatest Common Divisor In-Reply-To: <5E08D947.9000902@anastigmatix.net> Message-ID: References: <5E08D947.9000902@anastigmatix.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-CLAMAV-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrvdeffedgleekucetufdoteggodetrfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvufgjkfhffgggtgesthdtredttdervdenucfhrhhomhephfgrsghivghnucevqffgnffjqfcuoegtohgvlhhhohestghrihdrvghnshhmphdrfhhrqeenucfkphepkeekrddvudelrddvfeejrdehfeenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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.