From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Mon, 20 Aug 2018 19:50:00 +0000 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <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" X-Trace: blaine.gmane.org 1534794718 23890 195.159.176.226 (20 Aug 2018 19:51:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 19:51:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: andrewjmoreton@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 21:51:54 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 1frqDR-00065U-Jt for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 21:51:53 +0200 Original-Received: from localhost ([::1]:49018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frqFX-0002BR-Rc for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 15:54:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frqCW-0000hY-3m for emacs-devel@gnu.org; Mon, 20 Aug 2018 15:50:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frqCN-0002Jl-4C for emacs-devel@gnu.org; Mon, 20 Aug 2018 15:50:50 -0400 Original-Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:47032) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frqCG-0002CC-Jy for emacs-devel@gnu.org; Mon, 20 Aug 2018 15:50:43 -0400 Original-Received: by mail-lf1-x135.google.com with SMTP id e23-v6so6466972lfc.13 for ; Mon, 20 Aug 2018 12:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biORAU5g/NTRESoBjcmRGt08p+x3eswBtm99h//ds4c=; b=kXDVC71Y7Fi6OiFV/FmzZG9hRk1MmgVS7ogV4dQNgqrdCW1OuqMJ7KeSf3sP6amzD2 ++ZR1QV0sjpk8PG8lDZLzwGcadMdzEPhorhf4mtID+OAbWEjLB1YwXWba7Kvds+t+FfT szW2SpDWqQgL9L4tuWpkvRXtX1cgny3Ya3F+oo1PWue06NDA8cV6EVxChxO1z13VqqJh TpArONaGscJaU8aTNvwvq4ie0i0kxcKp5PW3TPfOhmuo2HEBEniY2zheU7oeVApXc2XS Sx5qkgIjhCoXqwjtBXnNj52PIfBrzX8kiLV8NbHpfN2A1fJG5GAlnnuykovyF9UnM5Du PdWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=biORAU5g/NTRESoBjcmRGt08p+x3eswBtm99h//ds4c=; b=iN4ngCnqLBN6WUIKNTvo1poxiAYsF9RNXBKeVJ1n2K/VRtp2WxCEyHmujs97gM/oLd iX7mkx7sTv97J3D2eoJTwtdav3lPC/N5HlVKp4soZ5K/4MH61LR4+C8mdX9WwtS8hvKD ODCIu2TEMOYYKYlA0I1XkRPlBxr4QwLgvbqWuJzO5pZz8KP1igQqJTD666H+eS2BMxUs aM+lIjMOBfOVHggLnSEj9BoO/ZVYqvQFNXKzNYuQvsP7zuX3G8URVqsHcfMHem0bUAjS PShlQEtRSlf+t4VyRDggyVKcutZUyGo/Y+IJhyprtIC01pTbI6e2w6SH2e2VrDVvTfT6 UjBg== X-Gm-Message-State: AOUpUlGJbDOVJFHoJ16ElAT24kdu5e9KPCUjFSTlfZ9fzpbD772L/vaQ da9R1d5DCJdMgAaEa35kyvyFhWz599dEhirE0Lk= X-Google-Smtp-Source: AA+uWPwgqu2OY35MTufiZTvsan+D6YP5TgQxuOjjw7RuYzHqvQbTNSM6SpNy++KQ0W9mAW49JwaU+lIj8uQ8ZJhaAww= X-Received: by 2002:a19:d095:: with SMTP id h143-v6mr29661720lfg.16.1534794639339; Mon, 20 Aug 2018 12:50:39 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::135 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:228760 Archived-At: On Mon, Aug 20, 2018 at 4:43 PM Andy Moreton wrote: > On Mon 20 Aug 2018, Paul Eggert wrote: > > > 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. > > Pip Cet was advocating removal of most-positive-fixnum, and that is what > I was objecting to as being too severe. We do not need negativep as we > already have other prmitives for testing that property. I'm sorry for the sloppy wording. `most-positive-fixnum' should stay: it's an important implementation detail. All the references to it in lisp/, though, look to me like they should be removed. The references in test/ should stay, for example, and I think a good case can be made that the fixnum range should be included in Emacs bug reports, which would be a legitimate use in the lisp/ directory. > >> 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. > > You have avoided the question. > > The current codebase assumes that lisp bignum objects only exist for > values outside fixnum range. Without fixnump how can tests check that > values within fixnum range actually have a fixnum representation ? How > can test check that no bignum object is created for a fixnum value ? I think keeping a Lisp function around for the sole purpose of testing C code from Lisp is wrong. The right thing to do in this case is to test the C code from C; I believe GCC does so extensively, and it would be easy enough to add a test function that eassert()s that FIXNUMP(Fsub1(Fadd1(MOST_POSITIVE_FIXNUM))), for example. Again, I think important implementation details, like what a good range for fast integer arithmetic is ([most-negative-fixnum, most-positive-fixnum]) and how floats are encoded and whether IEEE rules are being followed (IEEE_FLOATING_POINT), should be exposed to Lisp. (For example, I'm playing around with big rational numbers, and one possible implementation is for them to replace floats, but that almost naturally requires a ratio-to-nearby-simple-ratio function to avoid building up huge representations; whether to use such a function and what it does would be an implementation detail, but one that code might want to optimize for...) Does bignump serve a purpose other than testing C code? My impression is that it doesn't in the current implementation, and the symbol should be left unbound, but considered reserved. While there is hypothetical code that wants to know whether a number is currently encoded as a bignum (I'm thinking of benchmarking code that's run in a future Emacs with contrarily bignum-encoded fixnum-range integers), I think it's exotic enough that it can just test (if (fboundp 'fixnump) (fixnump x) (<= most-negative-fixnum x most-positive-fixnum)). Leaving bignump in will lead to people thinking it's synonymous to "is this number outside the fixnum range", and such code will then break if it's suddenly possible for (bignump 0) to be false. Perhaps a good analogy is that (bignump x) is on a level with "what C address is x stored at": it's a question only very curious Lisp programs would ask, and the answer is subject to change and dangerous to rely on.