From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: (*) -> 1 Date: Tue, 17 Jan 2023 18:17:53 +0100 Message-ID: <87h6wpkrlq.fsf@web.de> References: <87r0vuidjc.fsf@eder.anydns.info> <87y1q1kvdm.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34081"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:9pJn7Rt3i/wZmJT7LqYssW7MQEM= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 17 18:19:16 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHpcC-0008au-Cz for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 17 Jan 2023 18:19:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHpbb-0005pn-AR; Tue, 17 Jan 2023 12:18:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHpb3-0005fd-Dm for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 12:18:29 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHpb1-0005oK-Om for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 12:18:05 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pHpay-0006k5-W2 for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 18:18:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142320 Archived-At: Jean Louis writes: > Every elementary school is there to prove that convention of having at > least two addends for addition and two factors for multiplication > exists. Ok... My neighbor has one garage with 2 Ferraris. Altogether he has (+ 2) ==> 2 Ferraris. Not an undefined number of Ferraris. So you see that extending the sum operator to one summand is natural and makes sense. I OTOH have no garage. The number of my Ferraris in all my garages is (+) -> 0 Ferraries. The count of my Ferraris in all of my garages is actually defined, as the number of my garages is. It is really 0, not undefined. I can't write to the tax office that the number of Ferraris in my garages is undefined because there are zero summands and thus I can't calculate the number. > By chance, I am providing roomt to mathematics teacher who was not > introduced to this discussion, and I just called him and asked him if > there is anything that he knows that in absence of factors, the > multiplication operation would yield with anything, and he has no idea > what we are talking about. This convention is not so useful in elementary school, at least not literally. And unfortunately, at least here in Germany, a lot of mathematics teachers don't understand math very well. But you might have learned that multiplication is repeated summation (I think I already gave this example a couple of times but never got a response): 2*9 = 9 + 9 (two summands) 1*9 = 9 (one summand) 0*9 = ??? (it's 0 at least) When it's allowed for `*' to handle cases that could be interpreted (!) as the sum of zero arguments, why should a _generalization_ of `+' not be allowed to? Note that adding things like Ferraris is only an _interpretation_ of a formula. A product with zero factors might not have a useful direct interpretation in the real world, but complex numbers also don't have, and that doesn't mean that it can't be useful to extend the formalisms that once were _inspired_ by things in the real world. What sum corresponds pi^2 to? So what you fail to see is that not everything in maths can be directly demonstrated using apples and pears. But that doesn't mean that it's not worth to include these parts of maths in programming languages. If you are really doing maths, or are really working with sums in programming, you'll see why and where these convention make sense. And in programming, it's a bit like with everything new you learn: you don't miss it before you get to know it. > What idea he has is that there must be 2 known factors for > multiplications and similar for addition. That doesn't mean that it can't be _extended_. Like the natural numbers can be extended to the whole numbers etc. It's generalization and abstraction. You don't learn all of that in elementary school. > That there may be some convention is not excluded, and that there is > identity element in mathematics is fine, but even the page of identity > element does not speak of creation of identity elements, but of usage > of identity elements. It's just not important enough, it's a little detail. Like in Elisp. It might sound super important and big to you right now but we are speaking about a tiny corner case all the time. We don't mention that (* 0 n) returns 0 in the docstring of `*', for example. > Then we have contradiction that description of functions `*' and `+' > and `-' does not speak of any sets or group theory. And we have people > speaking yes, group theory, sets. > > But not description of relation from sets to Lisp function, why? We have argument _lists_ that play the role of sets. > I am asking why is it in (some) Lisps? Because it's more convenient than raising an error. Examples had been outlined in this thread. Michael.