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: bignum branch Date: Sat, 04 Aug 2018 14:07:36 +0300 Message-ID: <83effetmo7.fsf@gnu.org> References: <87o9fbbw1t.fsf@tromey.com> <86k1pxmvmx.fsf@gmail.com> <87efg4a9xc.fsf@tromey.com> <87a7qr8cz7.fsf@tromey.com> <86tvoy3je9.fsf@gmail.com> <86bmb0vbxf.fsf@gmail.com> <87k1pnfcg1.fsf@tromey.com> <86sh4b1833.fsf@gmail.com> <861sbgz3dm.fsf@gmail.com> <83a7q4ufxp.fsf@gnu.org> <86in4resc8.fsf@gmail.com> <831sbfvl11.fsf@gnu.org> <8636vv7ohh.fsf@gmail.com> <83y3dntwsw.fsf@gnu.org> <83wot7tkdh.fsf@gnu.org> <87y3dnyzkl.fsf@tromey.com> <42060bb4-3535-3b03-e007-0ae68134a30b@cs.ucla.edu> <87tvobywph.fsf@tromey.com> <83muu2u02o.fsf@gnu.org> <871sbez9sb.fsf@Rainer.invalid> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1533380747 1252 195.159.176.226 (4 Aug 2018 11:05:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2018 11:05:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 04 13:05:43 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 1fluNT-0000Eq-09 for ged-emacs-devel@m.gmane.org; Sat, 04 Aug 2018 13:05:43 +0200 Original-Received: from localhost ([::1]:54644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fluPZ-0002IP-DM for ged-emacs-devel@m.gmane.org; Sat, 04 Aug 2018 07:07:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fluPT-0002IK-CC for emacs-devel@gnu.org; Sat, 04 Aug 2018 07:07:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fluPQ-00058Z-8r for emacs-devel@gnu.org; Sat, 04 Aug 2018 07:07:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fluPQ-00058V-56; Sat, 04 Aug 2018 07:07:44 -0400 Original-Received: from [176.228.60.248] (port=4635 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fluPP-0001pr-Kw; Sat, 04 Aug 2018 07:07:44 -0400 In-reply-to: <871sbez9sb.fsf@Rainer.invalid> (message from Achim Gratz on Sat, 04 Aug 2018 12:49:24 +0200) 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:228150 Archived-At: > From: Achim Gratz > Date: Sat, 04 Aug 2018 12:49:24 +0200 > > Eli Zaretskii writes: > > There's a certain tension here between people who are used to do IEEE > > compliant FP math in other languages, and the rest of us. The former > > will want the IEEE semantics of NaNs, which is what surprised Tom; the > > latter will probably be surprised like Tom was. > > The semantics of NaN have not much to do with IEEE754 and a lot with how > you do error handling, which shouldn't be a surprise to any programmer. It won't surprise those of us who had to deal with FP calculations. I'm not so sure about others, because the semantics of FP exceptions is not necessarily known to them. > > I don't see how we can fix this dilemma better than we already did, > > with making sure eql compares NaNs as equal. I do think we should > > document the special behavior of NaNs, because many Emacs users will > > not be aware of these subtleties. > > Again, comparing the representations of an NaN (binary or otherwise) is > fair game. The NaN itself, as long as it propagates through a chain of > numerical computations, needs to be preserved; otherwise it'd be an > exercise in futility to produce them in the first place. If you don't > want to deal with NaN at all, there are other methods of handling > numerical domain errors, but they are usually worse (and often much more > so) than the alternative. Yes, I know. Others may not be aware of all those subtleties, which is exactly what I was saying in my original message.