From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Sun, 22 Jul 2018 09:44:43 -0700 Organization: UCLA Computer Science Department Message-ID: <5b3be3f4-d438-166a-863a-587c880584c8@cs.ucla.edu> References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <83bmecy6fx.fsf@gnu.org> <0d3175d8-d996-651e-b221-71978bde3a65@cs.ucla.edu> <87tvpdnzgy.fsf@tromey.com> <4c2a814f-c254-29e5-39cf-11b5f2e5c9c8@cs.ucla.edu> <49d8ba62-c9a5-9203-d882-8e900b441ff3@cs.ucla.edu> <8e0320d9-e0d0-2b57-57cc-2df4399f133c@cs.ucla.edu> <87lgaio7xd.fsf@tromey.com> <877em1cb0i.fsf@tromey.com> <765767b2-d2e5-a9a6-f724-d58ecf4847bb@cs.ucla.edu> <1452F858-C7FD-4AEB-BB85-D874692F918F@raeburn.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1532277778 7350 195.159.176.226 (22 Jul 2018 16:42:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jul 2018 16:42:58 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: Tom Tromey , emacs-devel@gnu.org, Stefan Monnier , Richard Stallman To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 22 18:42:53 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhHRa-0001hs-V0 for ged-emacs-devel@m.gmane.org; Sun, 22 Jul 2018 18:42:51 +0200 Original-Received: from localhost ([::1]:56719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fhHTg-0007ee-Aq for ged-emacs-devel@m.gmane.org; Sun, 22 Jul 2018 12:45:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fhHTW-0007c9-Cf for emacs-devel@gnu.org; Sun, 22 Jul 2018 12:44:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fhHTT-0001b7-AN for emacs-devel@gnu.org; Sun, 22 Jul 2018 12:44:50 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56492) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fhHTT-0001ap-1G; Sun, 22 Jul 2018 12:44:47 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B733C16081C; Sun, 22 Jul 2018 09:44:45 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 38RBV_RwJ0xd; Sun, 22 Jul 2018 09:44:44 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E0C21160825; Sun, 22 Jul 2018 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FJPhfTGtBepj; Sun, 22 Jul 2018 09:44:44 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6F11A16081C; Sun, 22 Jul 2018 09:44:44 -0700 (PDT) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <1452F858-C7FD-4AEB-BB85-D874692F918F@raeburn.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227679 Archived-At: Ken Raeburn wrote: > If we=E2=80=99re going to treat NaNs as having distinguishable bit patt= erns so we can tell whether two are the same or not, should we also have = printable/readable forms that distinguish them? If not, how do we create = and use distinguishable NaNs? Good point. It'd make sense to have printable/readable forms; please see = below. > are we guaranteed that operations like (/ 0.0 0.0) will always generate= NaNs with the same bit pattern? No, and this is an issue even with older Emacs. For example, (format "%s"= (/ 0.0=20 0.0)) returns different strings on different platforms, because some mach= ines=20 return a negative NaN whereas others don't. > I would=E2=80=99ve guessed that it might be preferable to go the other = direction, and use one canonical NaN value in Lisp, which would thus alwa= ys be eq/eql to all other NaN expressions. For some time Emacs has been able to distinguish negative from nonnegativ= e NaNs.=20 Functions like 'format' and 'copysign' depend on a NaN's sign, and (- x)=20 reliably changes the sign of a NaN. I see three ways to go here. 1. We change eql, memql, sxhash-eql, etc. to treat all NaNs alike, so tha= t there=20 is just one NaN value from the Lisp point of view. We also change 'format= ',=20 'copysign' etc. to ignore a NaN's sign, and look through any other use of= =20 floating-point values to make sure that NaN signs are ignored. 2. We change eql, memql, sxhash-eql, etc. so that only the sign (not the=20 significand) of a NaN is looked at, so that there are just two NaN values= from=20 the Lisp point of view. 3. We alter 'read', 'format' etc. to read and generate NaN significands. = For=20 example, (format "%s" NaN) could return "0.1e+NaN" if the significand's=20 low-order bit was set. (1) sounds too drastic, as the sign of a NaN can be useful in some cases = and=20 Emacs has long provided for obtaining the sign of a NaN. Although either = (2) or=20 (3) would be OK, I'm inclined to go for (3) as I expect it would be a bit= =20 cleaner and more useful.