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: Thu, 19 Jan 2023 12:05:32 +0300 Message-ID: References: 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="3595"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: "tomas@tuxteam.de" , "help-gnu-emacs@gnu.org" , Paul Eggert To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 19 10:19:37 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 1pIR56-0000ji-Pv for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 19 Jan 2023 10:19:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIQtg-0000iO-Pt; Thu, 19 Jan 2023 04:07:48 -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 1pIQtf-0000i9-Ae for help-gnu-emacs@gnu.org; Thu, 19 Jan 2023 04:07:47 -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 1pIQtd-0003YL-Gg for help-gnu-emacs@gnu.org; Thu, 19 Jan 2023 04:07:47 -0500 Original-Received: from localhost ([::ffff:197.239.7.243]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010394D.0000000063C90863.00002453; Thu, 19 Jan 2023 02:07:47 -0700 Mail-Followup-To: Drew Adams , "tomas@tuxteam.de" , "help-gnu-emacs@gnu.org" , Paul Eggert Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-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:142385 Archived-At: Hello Paul, I suppose you made (*) ➜ 1 function as such, please see and let me know if you know the reason why you added it. Too much was told about it on mailing list, but I can't find reasons. People tried to explain it with mathematics. Was the reason mathematical set theory? What was reason for your change in the `*' function back in 2018? * Drew Adams [2023-01-18 23:37]: > See the code I provided. Passing a list of values > to a unary `foo': > > (foo '(3 6 9)) > (foo '(2)) > (foo ()) > > Passing multiple values to a variable-arity `foo': > > (foo 3 6 9) > (foo 2) > (foo) I understand that idea and understood in first time. Only that it does not fit in general context of any function. And explanation tries to fit it for every function. > > Without practical use I can only tell it is capricious decision. > > Without using it or understanding it you can > continue to think so, I suppose. And how can I understand if none of participants demonstrated the use? Not mentioning justifications how somewhere outside of Lisp something exists theoretically... that outside is not Emacs Lisp. > > Maybe we can tell it this way: > > If there is any Emacs Lisp program which does not use (*) or (* a) > > anywhere but which would raise error if we re-define function > > to require 2 arguments -- then there must be some use of it. > > How about + or * with more than 2 args? Do you > think allowing that is also useless imagination, > a capricious decision, madness imposed by useless > mathematicians? My question was simple. You counter with questions. Deviation from straight answer does not make it an answer. If there is any Emacs Lisp program which does not use (*) or (* a) anywhere but which would raise error if we re-define function to require 2 arguments? It is not a mind boggling question, it is practical question to understand if there is use of it. What is mind boggling is that people explain how it must be so, without showing use for it. I can make my private functions as I want, I can return funny stuff like "Doomed", and I can justify it that I don't like raising errors, or that I have seen game which gave me the idea to return that result. I believe there is plausible explanation which was not mentioned in the mailing list, as somebody must have the answer for it. Trying to explain it by using mathematics outside of Emacs without showing me use of it does not give me understanding. I am trying to search to root of it, and I find that function is defined as this: DEFUN ("*", Ftimes, Stimes, 0, MANY, 0, doc: /* Return product of any number of arguments, which are numbers or markers. usage: (* &rest NUMBERS-OR-MARKERS) */) (ptrdiff_t nargs, Lisp_Object *args) { if (nargs == 0) return make_fixnum (1); Lisp_Object a = check_number_coerce_marker (args[0]); return nargs == 1 ? a : arith_driver (Amult, nargs, args, a); } but back in time it was defined as following: https://github.com/emacs-mirror/emacs/blob/8f3a2c2659ddee1ae84b4b8bb28f6c388f87fd0f/src/data.c DEFUN ("*", Ftimes, Stimes, 0, MANY, 0, doc: /* Return product of any number of arguments, which are numbers or markers. usage: (* &rest NUMBERS-OR-MARKERS) */) (ptrdiff_t nargs, Lisp_Object *args) { return arith_driver (Amult, nargs, args); } and that was in August 5, 2013, and then by searching commmits, I can find: August 28, 2018, it was not there!!! Does that mean all of explanations by participants were not valid before that date? Then I look at the first time it appeared in Emacs: https://github.com/emacs-mirror/emacs/blob/fe042e9d15da7863b5beb4c2cc326a62d2c7fccb/src/data.c Improve arithmetic performance by avoiding bignums until needed. Also, simplify bignum memory management, fixing some unlikely leaks. This patch improved the performance of (+ 2 2) by a factor of ten on a simple microbenchmark computing (+ x 2), byte-compiled, with x a local variable initialized to 2 via means the byte compiler could not predict: performance improved from 135 to 13 ns. The platform was Fedora 28 x86-64, AMD Phenom II X4 910e. Performance also improved 0.6% on ‘make compile-always’. * src/bignum.c (init_bignum_once): New function. * src/emacs.c (main): Use it. * src/bignum.c (mpz): New global var. (make_integer_mpz): Rename from make_integer. All uses changed. * src/bignum.c (double_to_bignum, make_bignum_bits) (make_bignum, make_bigint, make_biguint, make_integer_mpz): * src/data.c (bignum_arith_driver, Frem, Flogcount, Fash) (expt_integer, Fadd1, Fsub1, Flognot): * src/floatfns.c (Fabs, rounding_driver, rounddiv_q): * src/fns.c (Fnthcdr): Use mpz rather than mpz_initting and mpz_clearing private temporaries. * src/bignum.h (bignum_integer): New function. * src/data.c (Frem, Fmod, Fash, expt_integer): * src/floatfns.c (rounding_driver): Use it to simplify code. * src/data.c (FIXNUMS_FIT_IN_LONG, free_mpz_value): Remove. All uses removed. (floating_point_op): New function. (floatop_arith_driver): New function, with much of the guts of the old float_arith_driver. (float_arith_driver): Use it. (floatop_arith_driver, arith_driver): Simplify by assuming NARGS is at least 2. All callers changed. (float_arith_driver): New arg, containing the partly converted value of the next arg. Reorder args for consistency. All uses changed. (bignum_arith_driver): New function. (arith_driver): Use it. Do fixnum-only integer calculations in intmax_t instead of mpz_t, when they fit. Break out mpz_t calculations into bignum_arith_driver. (Fquo): Use floatop_arith_driver instead of float_arith_driver, since the op is known to be valid. (Flogcount, Fash): Simplify by coalescing bignum and fixnum code. (Fadd1, Fsub1): Simplify by using make_int. As I cannot decipher above, does that mean that (*) ➜ 1 was added only for reason to speed up some C functions in Emacs? Is that the reason Paul? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/