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: Making 'eq' == 'eql' in bignum branch Date: Mon, 20 Aug 2018 09:03:17 -0700 Organization: UCLA Computer Science Department Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <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> <76081b5d-8c10-0a37-2c97-d4864c0faa80@cs.ucla.edu> <09153aed-361d-4f82-d9ac-b502314769ae@cs.ucla.edu> <861sato21d.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534781537 9537 195.159.176.226 (20 Aug 2018 16:12:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 16:12:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 To: Andy Moreton , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 18:12:13 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 1frmmp-0002L3-Ha for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 18:12:11 +0200 Original-Received: from localhost ([::1]:48022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frmow-0001lu-0L for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 12:14:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frmoQ-00015y-Cj for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:13:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frmeI-0003nH-39 for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:03:25 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51652) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1frmeH-0003kx-F8 for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:03:21 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 44262160EBD; Mon, 20 Aug 2018 09:03:20 -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 q123uufYbjC4; Mon, 20 Aug 2018 09:03:18 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4ACAE160EC0; Mon, 20 Aug 2018 09:03:18 -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 QKG6aKgAKGYs; Mon, 20 Aug 2018 09:03:18 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0947F160EBD; Mon, 20 Aug 2018 09:03:17 -0700 (PDT) In-Reply-To: <861sato21d.fsf@gmail.com> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:228736 Archived-At: Andy Moreton wrote: > There will always be a performance diffrence between fixnum and bignum > values, and it may be useful for performance tuning to have a simple way > to discover where that boundary lies. Performance nerds can use 'most-positive-fixnum' and 'most-negative-fixnum' for that sort of thing. These constants have been there for some time and are not going away. My objection is to 'bignump' and 'fixnump', which are no more necessary as primitives than 'negativep' would be. > These are used in the tests to ensure that implementation is correct, > and that values in fixnum range are always represented as fixnums, not > bignums. How do you propose to test that without these predicates ? Tests can use 'most-positive-fixnum' and 'most-negative-fixnum', constants that tests need to use anyway in order to generate values like (1+ most-positive-fixnum). So they can survive quite well without 'bignump' and 'fixnump' as primitives.