From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Floating-point constant folding in Emacs byte compiler Date: Mon, 02 Apr 2018 15:50:58 +0300 Message-ID: <83zi2l6abx.fsf@gnu.org> 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> <83370d7szw.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522673374 897 195.159.176.226 (2 Apr 2018 12:49:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Apr 2018 12:49:34 +0000 (UTC) Cc: rpluim@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 02 14:49:29 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 1f2ytt-00007Q-8b for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2018 14:49:29 +0200 Original-Received: from localhost ([::1]:60676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2yvx-0005Th-2G for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2018 08:51:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2yvI-0005Sm-Vn for emacs-devel@gnu.org; Mon, 02 Apr 2018 08:50:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f2yvF-0008Jy-Sp for emacs-devel@gnu.org; Mon, 02 Apr 2018 08:50:57 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2yvF-0008Jr-OT; Mon, 02 Apr 2018 08:50:53 -0400 Original-Received: from [176.228.60.248] (port=2288 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f2yvF-00034n-89; Mon, 02 Apr 2018 08:50:53 -0400 In-reply-to: (message from Pip Cet on Mon, 2 Apr 2018 11:42:59 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:224239 Archived-At: > From: Pip Cet > Date: Mon, 2 Apr 2018 11:42:59 +0000 > Cc: eggert@cs.ucla.edu, rpluim@gmail.com, emacs-devel@gnu.org > > I'm trying to make bytecode reproducible for my code, which uses > SpiderMonkey's JS::Value type, and in which two same-value floats are > always equal (because their bit representations are), and standard > Emacs on a standard GNU/Linux machine, where, as I've just learned, > two same-value floats are never eq (I'd previously thought that was > undefined, and actually unpredictable in practice). Well, maybe what I said could be misinterpreted: they _can_ be EQ iff they reference the same Lisp_Float object. If they reference different objects, they aren't EQ. When these floats come from Lisp, it's extremely unlikely for them to reference the same object, though. > Again, this is the first time I hear that "two floats are never EQ" is > actually intentional behavior that some code might rely on, rather > than a mere accident of the current float implementation. Do you > happen to have any examples at hand for code that relies on this? Not off the top of my head, no. But IME such implementation details tend to leak into the code, and I would be surprised if we didn't have something like that in Emacs. > In the case of byte code, what I've seen so far is that the code > generated is actually suboptimal, and runs fine without duplicated > float constants in the constants vector. Comparing FP values for equivalence on the C level is tricky at best, due to extended precision, guard bits, etc. What is your plan for overcoming these obstacles in a predictable and reliable manner? Did you consider solving the problem the other way around, i.e. teaching JS::Value about this issue? (Caveat: I know nothing about JS.)