From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Fri, 31 Aug 2018 19:59:42 +0000 Message-ID: <20180831195942.GA4898@ACM> References: <0F8F6E54-176C-48EE-9E7C-7CAC424D0D55@raeburn.org> <352c998a64c646b983a131039e9c732b@lanl.gov> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1535745486 17338 195.159.176.226 (31 Aug 2018 19:58:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2018 19:58:06 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: "cpitclaudel@gmail.com" , Pip Cet , "emacs-devel@gnu.org" To: "Herring, Davis" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 31 21:58:02 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 1fvpYP-0004LC-AN for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2018 21:58:01 +0200 Original-Received: from localhost ([::1]:58103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvpaV-0004RN-Ja for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2018 16:00:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvpaO-0004PI-QK for emacs-devel@gnu.org; Fri, 31 Aug 2018 16:00:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvpaL-00089R-JF for emacs-devel@gnu.org; Fri, 31 Aug 2018 16:00:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:32540 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fvpaL-00087Z-BX for emacs-devel@gnu.org; Fri, 31 Aug 2018 16:00:01 -0400 Original-Received: (qmail 81205 invoked by uid 3782); 31 Aug 2018 19:59:59 -0000 Original-Received: from acm.muc.de (p5B146A99.dip0.t-ipconnect.de [91.20.106.153]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 31 Aug 2018 21:59:58 +0200 Original-Received: (qmail 5899 invoked by uid 1000); 31 Aug 2018 19:59:42 -0000 Content-Disposition: inline In-Reply-To: <352c998a64c646b983a131039e9c732b@lanl.gov> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:229147 Archived-At: Hello, Davis. On Wed, Aug 29, 2018 at 03:42:26 +0000, Herring, Davis wrote: > > Such a name should make clear that we're talking about a signed > > infinity, not one that makes 1/x continuous by adding a point at > > infinity to the real line. > Sure: the extended reals > , not the > projective reals > . > > Signed infinities are convenient symbols, but they're not numbers; I > > recall the horrified reaction of a mathematician when I told her > > about IEEE infinities (she thought I was making it up about NaNs). > Of course +/-inf are numbers. I'm speaking not as a mathematician, but as somebody with a degree in maths. +/-infinity are not numbers. They do not satisfy the axioms which define numbers. For example they do not satisfy (x + y) + z = x + (y + z) . They cannot be made to satisfy these axioms. > They're not real numbers, but neither are complex numbers, > split-complex numbers, dual numbers, p-adic numbers, quaternions, > octonions, sedenions, hyperreal numbers, or (please no) surreal > numbers. That's a strawman. The issue being discussed here is numbers, not arbitrary algebraic structures. > With all due respect to your mathematician friend, .... That is offensive in the extreme. > .... she has no exclusive claim over the definition (such as it is) of > "number" That's analagous to saying that climate scientists don't have the exclusive say-so about climate change. Ha ha, who needs experts? Mathematicians are _experts_ on numbers, with a deep understanding of their definitions, properties, and limitations. I would have expected, in this mailing list (as contrasted with lesser forums) to see respect for expertise, not disparagement. > (and I'm a bit surprised if she hadn't heard of at least one of the > extended real lines I linked). Again, offensive. "Infinity", with or without a sign, might be classed as an "extended number", but as noted above, is not a number. > NaN, on the other hand, is of course a floating-point value that > explicitly claims not to be a number. I'm not sure whether to believe > it; it seems very useful that the operations on floating-point > "numbers" are closed, but that depends on NaN being one of them... NaN is not a number, either, for much the same reasons. If you actually attempt to do anything numerical with NaN you will run into trouble. There have been discussions about the Lisp functions max and min being called without arguments. Some people have advocated that non-numbers be returned in such cases. I request most earnestly that this is not done. Callers of these functions have a right to assume that returned results are mathematically correct and that they can do arithmetic with them. Currently, max and min throw errors if called with no arguments. This is surely the right thing to do, and we should carry on doing it. > Davis -- Alan Mackenzie (Nuremberg, Germany).