From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: (*) -> 1 Date: Tue, 17 Jan 2023 21:04:18 +0300 Message-ID: References: <87r0vuidjc.fsf@eder.anydns.info> <87y1q1kvdm.fsf@web.de> <87h6wpkrlq.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36698"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 17 19:05:29 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 1pHqKu-0009Lf-EC for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 17 Jan 2023 19:05:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHqKA-0005hb-Tg; Tue, 17 Jan 2023 13:04:42 -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 1pHqK9-0005gq-7c for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 13:04:41 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHqK7-0000R8-4x for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 13:04:40 -0500 Original-Received: from localhost ([::ffff:102.85.233.9]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000056100.0000000063C6E338.000029F9; Tue, 17 Jan 2023 11:04:40 -0700 Mail-Followup-To: Michael Heerdegen , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87h6wpkrlq.fsf@web.de> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:142327 Archived-At: * Michael Heerdegen [2023-01-17 20:20]: > 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) and how do you use represent that in Emacs Lisp? Though we actually speak of following * = 1 because it is absence of summands. Not presence. > 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? Above sounds as capricious decision. I assume that Lisp makers who decided that (*) ➜ 1 did not have capricious decision, but they had something else in mind, something we did not yet mention here, and that something is what I am searching. > 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? I don't really search for useful interpretation in real world, just in Emacs Lisp or similar, why is it useful in Lisp? Do you have mathematical exercise in Lisp that may demonstrate it usefulness? Is it only for representation purposes like Eduardo explained, something like: (* 2 2 2) ➜ 8 (* 2 2) ➜ 4 (* 2) ➜ 2 (*) ➜ 1 Do you think it is only for representation or consistency purposes? Or there is some actual use? > So what you fail to see is that not everything in maths can be > directly demonstrated using apples and pears. I don't fail to see that, because I know that 2 plus 2 is never 4, that is just absolute representation, and in reality (almost) not possible, as things like apples or Ferraris, chips, they are never same, we have to imagine that one thing is same to other for mathematics to work, as there is useful application of it. So no, that is not problem. What I do not see is why is it convenient in Lisp. > But that doesn't mean that it's not worth to include these parts of > maths in programming languages. OK I understand people in Common Lisp included it, and Emacs Lisp has it, and other Lisps. But why for example Emacs Lisp has (-) ➜ 0 but other Lisps not? Maybe in Emacs Lisp authors found some use for it? Or do they include it just because? Just because set theory, blah blah, so let us include it, but we see no reason for it. This is not believable. I believe there is some practical reason behind it. Reason that was not yet shown, but I feel it may be shown by somebody. > If you are really doing maths, or are really working with sums in > programming, you'll see why and where these convention make sense. I have no doubt for it. But show me use in Lisp as I do not ask about outside theories, but why is it included in Lisp. Is there example? > And in programming, it's a bit like with everything new you learn: > you don't miss it before you get to know it. It still remains mystery. > > 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. Ok it has been extended. That is your conclusion. But why? Show me the use. > > 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. I do not see above as analogous. I wish though. > > 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. OK, maybe that, I would like to understand if that was really the reason of including it, the reason to minimize errors? I remember keyword "variadic functions", and by you telling me that reason is to minimize errors, then I searched and found following: http://www.google.com/search?hl=en-UG&source=hp&biw=&bih=&q=reason+for+variadic+functions+in+lisp+%22%28*%29%22&iflsig=AK50M_UAAAAAY8bsWwouJNovTEERdNcNKZHzCAJ9q4qm&gbv=2&oq=reason+for+variadic+functions+in+lisp+%22%28*%29%22&gs_l=heirloom-hp.3..0i546l3j0i30i546.87530.93919.0.94212.43.40.0.1.1.1.283.4416.20j15j5.40.0....0...1ac.1.34.heirloom-hp..16.27.2252.UY2UeNCa7OY I see one reference here: Lots of Insipid, Stupid Parentheses | by Ronie Uliana | Medium: https://ronie.medium.com/lots-of-insipid-stupid-parentheses-98f9b9510579 where it says: "Variadic arguments are even more interesting when we don’t pass any argument, like this: (+) <= this one gives us 0 (*) <= and this results in 1 Very handy because those are exactly the neutral elements for sum and product." But I can't see why is it handy, why it was added to Lisp to be handy. I heard so far it is convenient, handy, but not why is it convenient, no example where it shows its conveniency, and Picolisp example shows that `apply' can work perfectly well even if (*) ➜ NIL I can see here at this reference: Lots of Insipid, Stupid Parentheses | by Ronie Uliana | Medium: https://ronie.medium.com/lots-of-insipid-stupid-parentheses-98f9b9510579 > Variadic functions are functions that can take a variable number of > arguments. In C programming, a variadic function adds flexibility to > the program. It takes one fixed argument and then any number of > arguments can be passed. The variadic function consists of at least > one fixed variable and then an ellipsis(…) as the last parameter. That gives me to think that the sole purpose of making (*) ➜ 1 work in Lisp is to minimize errors, though I do not see the useful Lisp expression where such error is minimized. I wish to find it. The only useful case where I see that (*) will minimize errors is the function itself, by writing "(*)" so in that case it minimizes errors, so that demonstration is not enough. Is there any other case or Lisp expression where one can see that (*) is useful to minimize errors? I can think that such case is maybe every day easy to find, but so far none of participants mentioned it. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/