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: Floating-point constant folding in Emacs byte compiler Date: Fri, 30 Mar 2018 09:39:05 -0700 Organization: UCLA Computer Science Department Message-ID: References: <2ce39e5c-cd1b-65d6-b125-719caad67932@cs.ucla.edu> <83vadmgfbz.fsf@gnu.org> <87d0zr2n1u.fsf@gmail.com> <83h8p2g99p.fsf@gnu.org> <87370m3k4y.fsf@gmail.com> <838taeg6z5.fsf@gnu.org> <7a49cbdf-f2c3-0803-2ee8-3d9f55e405a5@cs.ucla.edu> <7a4f10ec-c1b9-953d-7a95-b2f1ff762735@cs.ucla.edu> 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 1522427837 15483 195.159.176.226 (30 Mar 2018 16:37:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 16:37:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Robert Pluim , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 30 18:37: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 1f1x1b-0003tW-VW for ged-emacs-devel@m.gmane.org; Fri, 30 Mar 2018 18:37:12 +0200 Original-Received: from localhost ([::1]:51925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1x3f-00087W-JS for ged-emacs-devel@m.gmane.org; Fri, 30 Mar 2018 12:39:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1x3X-00084b-Pe for emacs-devel@gnu.org; Fri, 30 Mar 2018 12:39:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1x3U-00088X-NA for emacs-devel@gnu.org; Fri, 30 Mar 2018 12:39:11 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37260) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f1x3U-00088K-HJ for emacs-devel@gnu.org; Fri, 30 Mar 2018 12:39:08 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BC3111616E7; Fri, 30 Mar 2018 09:39:06 -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 0p5ooMzD2YGu; Fri, 30 Mar 2018 09:39:06 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 184241616F4; Fri, 30 Mar 2018 09:39:06 -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 sZAMjw5TSYOx; Fri, 30 Mar 2018 09:39:06 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id F24EB1616E7; Fri, 30 Mar 2018 09:39:05 -0700 (PDT) In-Reply-To: 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:224184 Archived-At: On 03/30/2018 09:26 AM, Pip Cet wrote: > with optimization, > (lambda () (eq 1024.0 1024.0)) will still be false, but without > optimization, it will turn into bytecode that always returns true This problem is endemic to Lisp implementations and I wouldn't worry about it too much. In Scheme, for example, it is unspecifed whether (eq? 2.0 2.0) returns true or false, and Emacs Lisp could do the same. We'll have similar problems with bignums if we ever get around to implementing them.