From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Sat, 1 Sep 2018 00:47:36 -0400 Message-ID: <6bd2c0da-fba9-a875-6b7a-e6d80b39de79@gmail.com> References: <0F8F6E54-176C-48EE-9E7C-7CAC424D0D55@raeburn.org> <352c998a64c646b983a131039e9c732b@lanl.gov> <20180831195942.GA4898@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1535777153 1794 195.159.176.226 (1 Sep 2018 04:45:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Sep 2018 04:45:53 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: Pip Cet , "emacs-devel@gnu.org" To: Alan Mackenzie , "Herring, Davis" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 01 06:45:48 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 1fvxn9-0000MF-5x for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2018 06:45:47 +0200 Original-Received: from localhost ([::1]:59519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvxpF-00006r-FW for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2018 00:47:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvxoy-0008MV-Pi for emacs-devel@gnu.org; Sat, 01 Sep 2018 00:47:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvxox-0001la-Rm for emacs-devel@gnu.org; Sat, 01 Sep 2018 00:47:40 -0400 Original-Received: from mail-yw1-xc2d.google.com ([2607:f8b0:4864:20::c2d]:47080) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fvxox-0001jw-Ma for emacs-devel@gnu.org; Sat, 01 Sep 2018 00:47:39 -0400 Original-Received: by mail-yw1-xc2d.google.com with SMTP id j131-v6so5753192ywc.13 for ; Fri, 31 Aug 2018 21:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZljAMLvkGHiug5HcE+ZgFfYHKpsZcmWxQa9D0jmTPdU=; b=ZrlAMYaRwhx6im3InqBuXIio0kr4EYBrhLGxBU55OekhLD711gjX+Q3dJUWlGnUFTL ayTuRtm0R8K4cp6XQ4lt5w9CN7Su1BOpPDkJmdgR7DzTzqof+EcCI3hLP1T1J+Kjm5mi xJ/kqMQ7qVso9J+URKJJDOSx/4wQnVMAjwE1WHdnqZ7LeHqwdUCAKmGuSwQgcBHbMgJi d5eKEe9XRRkSkoNczC1Wnkzaxa44ELEKx5QeZoSxhRVoNJ4gZvl29FKDeNl7oi7WuIvk YU6cg8sHFPirrfS712slA1YEg5ts4dxvEAXjE+hqIh8J2QRrdpNltEN94/93v14arhLB cyaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZljAMLvkGHiug5HcE+ZgFfYHKpsZcmWxQa9D0jmTPdU=; b=QcMvL6onvXy5vNt3QxDATm88vkB8H3ictWKHADnFV8KlkLIYPwHo5OONP5C/Go6B3r q2zHAvk21O1kwNmxj6IEv2l7qrnv5DtZYqvdIDXkGPKeFyZN0/Eqgg0ENbvvs7eUb7zV y/r6FPRH78fkzYJc/ZvQtxF5+n/25LUXXXBumsmR7qTmdMBU8bv/LIVSiMrjLdbdFk1s 8HrNHZ30WxPoCJhCLCXrmgiYbrbuc1aU3ePMeRbl0Yr5WBzNo3yM36dbIvzlB1rQ411A /PwTMcB1JBngajfefQhkSsGGX6YYWN23fREhFnEuXmBm6/Df1jQKjR7fDwHbVhaNrXHS BA7w== X-Gm-Message-State: APzg51DdfU1wqTzG7DbqpVXFXs6L/1B+7rAOuXXsqmHmn/TQ6aG1zY6q xlD6agKO0ti2IoH5QBfmZb7UGKZf X-Google-Smtp-Source: ANB0VdZvySCR0D6pFu7OxASlljIaSl4FGwMtmWEaz/1YiXQH/+D3Wswz4EGN1NjjWeBnVCsIOpHHGw== X-Received: by 2002:a0d:c903:: with SMTP id l3-v6mr10476871ywd.404.1535777258817; Fri, 31 Aug 2018 21:47:38 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:5426:d330:7055:3134? ([2601:184:4180:66e7:5426:d330:7055:3134]) by smtp.gmail.com with ESMTPSA id 84-v6sm4256688ywo.15.2018.08.31.21.47.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Aug 2018 21:47:38 -0700 (PDT) In-Reply-To: <20180831195942.GA4898@ACM> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::c2d 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:229155 Archived-At: Hi again Alan, Thanks for your thoughtful response! On 2018-08-31 15:59, Alan Mackenzie wrote: > 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. Thinking more about your message, I'm not sure I agree with this point, either. I don't know about the US or Germany, but at least in France it is common to define inf and sup as functions from ℝ into ℝ ∪ {–∞, +∞}, the extended real number line. With these definitions, inf(∅) is customarily set to +∞, and sup(∅) is set to +∞. https://en.wikipedia.org/wiki/Empty_set#Extended_real_numbers says: Since the empty set has no members, when it is considered as a subset of any ordered set, then every member of that set will be an upper bound and lower bound for the empty set. For example, when considered as a subset of the real numbers, with its usual ordering, represented by the real number line, every real number is both an upper and lower bound for the empty set. When considered as a subset of the extended reals formed by adding two "numbers" or "points" to the real numbers, namely negative infinity, denoted −∞, which is defined to be less than every other extended real number, and positive infinity, denoted +∞, which is defined to be greater than every other extended real number, then: sup ∅ = min({−∞, +∞} ∪ R) = −∞ and inf ∅ = max({−∞, +∞} ∪ R) = +∞ That is, the least upper bound (sup or supremum) of the empty set is negative infinity, while the greatest lower bound (inf or infimum) is positive infinity. By analogy with the above, in the domain of the extended reals, negative infinity is the identity element for the maximum and supremum operators, while positive infinity is the identity element for minimum and infimum. I could be convinced that returning −∞ and +∞ is wrong based on the fact that inf and sup are not min and max, and that the outputs of min and max should be elements of the sets they operate on; conversely, I'm also receptive to the convenience aspect or min and max returning infinities; but all in all I don't find the "numberness" argument particularly compelling, based on the reasoning outlined above. Clément.