Re: (*) -> 1

[Jean Louis]

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 <drew.adams@oracle.com> [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/