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 1ilGcP-0003q7-KD for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Dec 2019 18:15:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ilGcO-0002Rk-60 for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Dec 2019 18:15:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ilGcN-0002Rd-Ti for pgsql-hackers@lists.postgresql.org; Sat, 28 Dec 2019 18:15:15 +0000 Received: from courriel.mines-paristech.fr ([77.158.173.149] helo=antispam-1.ensmp.fr) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ilGcG-0004Wp-Qt for pgsql-hackers@lists.postgresql.org; Sat, 28 Dec 2019 18:15:15 +0000 Received: from smtp-5.mines-paristech.fr (smtp.mines-paristech.fr [77.158.173.146]) (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 3375257C80; Sat, 28 Dec 2019 19:15:07 +0100 (CET) Received: from pc54.home (agrenoble-653-1-42-9.w92-129.abo.wanadoo.fr [92.129.130.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-5.mines-paristech.fr (Postfix) with ESMTPSA id 7E23E2013D; Sat, 28 Dec 2019 19:15:06 +0100 (CET) Date: Sat, 28 Dec 2019 19:15:03 +0100 (CET) From: Fabien COELHO X-X-Sender: fabien@pseudo To: Vik Fearing cc: PostgreSQL Hackers Subject: Re: Greatest Common Divisor In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2056645051-1183991715-1577556906=:24861" X-CLAMAV-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrvdeftddgudduvdcutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffujgfkfhgfgggtsehmtderredtreejnecuhfhrohhmpefhrggsihgvnhcuvefqgffnjffquceotghovghlhhhosegtrhhirdgvnhhsmhhprdhfrheqnecuffhomhgrihhnpegvnhhsmhhprdhfrhenucfkphepledvrdduvdelrddufedtrdelnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2056645051-1183991715-1577556906=:24861 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Bonsoir Vik, > I recently came across the need for a gcd function (actually I needed > lcm) and was surprised that we didn't have one. Why not. > So here one is, using the basic Euclidean algorithm.  I made one for > smallint, integer, and bigint. Should pg provide the LCM as well? Hmmm, probably not, too likely to overflow. Should there be a NUMERIC version as well? I'd say maybe yes. I'm wondering what it should do on N, 0 and 0, 0. Raise an error? Return 0? Return 1? return N? There should be some logic and comments explaining it. I'd test with INT_MIN and INT_MAX. Given that there are no overflows risk with the Euclidian descent, would it make sense that the int2 version call the int4 implementation? C modulo operator (%) is a pain because it is not positive remainder (2 % -3 == -1 vs 2 % 3 == 2, AFAICR). It does not seem that fixing the sign afterwards is the right thing to do. I'd rather turn both arguments positive before doing the descent. Which raises an issue with INT_MIN by the way, which has no positive:-( Also, the usual approach is to exchange args so that the largest is first, because there may be a software emulation if the hardware does not implement modulo. At least it was the case with some sparc processors 25 years ago:-) See for instance (the int min value is probably not well handled): https://svn.cri.ensmp.fr/svn/linear/trunk/src/arithmetique/pgcd.c Basically, welcome to arithmetic:-) -- Fabien. --2056645051-1183991715-1577556906=:24861--