help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (*) -> 1


From: Óscar Fuentes
Subject: Re: (*) -> 1
Date: Tue, 17 Jan 2023 20:04:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Jean Louis <bugs@gnu.support> writes:

> * Óscar Fuentes <ofv@wanadoo.es> [2023-01-17 21:13]:
>> This is not about Mathematics, it is about notation, that means,
>> convention, that means, convenience.
>> 
>> In other programming languages an expression such as "+ 2" would yield a
>> partially applied function:
>> 
>> let f = + 2
>> f 5
>> -> 7
>> 
>> Lisp (or some implementations of it) went the route of "+ sums a list of
>> numbers." That's fine, and in that sense having (+) -> 1 is reasonable,
>> but there is nothing in Mathematics that says that it must be so instead
>> of yielding partially applied function, or simply throwing an error
>> message. Lisp's option is a consequence of its syntax (notation).
>
> Okay, but in C language definition of function `+' I see that if no
> arguments are supplied the result shall be 0, or for `*' the result
> shall be 1. So I see it from authoring side being something of
> importance, not from syntax side, as author, programmer, maybe
> Stallman, he could as well hande those functions with error, there was
> some reason why they deliberately explicitly decided to provide
> identity in absence of any arguments.
>
> At least I feel closer to solution after looking at "variadic
> functions".
>
> In the sense of minimizing errors, I have no example, is hard to
> understand that is the reason. In fact I need errors with many
> functions, as they are useful.
>
> I would not like really in my mathematical functions to get result 1
> if I for example forgot to write something, instead of writing:
>
> (setq hours 10) ➜ 10
> (setq interval 2) ➜ 2
> (setq waiting-time 2) ➜ 2
> (setq my-appointment (+ hours (* interval waiting-time))) ➜ 14
> so if I write by mistake following:
> (setq my-appointment (+ hours (*))) ➜ 11
>
> I would not like that mistake being there, as that would by my typo,
> and I need error, and not silent ignorance that I missed to write some
> arguments. 
>
> I have given one example why and how I understand that function `*'
> would be more useful to yield the erorr, then 1.
>
> What I am searching is why is (*) function useful to yield 1 in some
> example. Do you have it? Can you maybe think of one?

I think your confusion comes from an assumption that everybody else on
this conversation is blind to, in the sense that nobody (I didn't read
most of the thread, though) didn't explicitly stated it:

+ in Elisp is not the "plus" operation that we all know (the same C uses
and school children use.) + in Elisp is not the binary operation, it is
the summatory operator, which takes a list of arguments and returns the
sum of them all.

In that sense, maybe you can see more naturally that "the sum of nothing
is zero." This makes possible to apply the + (summatory!) operator to
any list of numbers, including the empty list.

As for the * operator, it is the same case as +, with the caveat of not
being so obvious that the multiplication of and empty list of numbers is
1. Here we choose convenience: as it is interesting to have all those
n-adic operators work for an arbitrary number of arguments (including 0)
we chose to return the "identity element" of the underlaying operation.

The "identity element" e for a binary operation $ is the element that
yields

e $ n -> n
n $ e -> n

for all n. So for the logior case in your other message 0 is the
identity element, as (logior n 0) -> (logior 0 n) -> n for all n.

The language designers pursue convenience and consistency and take
decisions based on some sense of what is "natural". Hence if we see as
reasonable that the summatory of an empty list of arguments is zero (the
identity element for summation) and we want for as much operators as
possible to work on empty lists, we also choose to return the empty
element for the underlaying operation of the operator on those cases.
There are more supporting "reasons" for doing that, such as:

(* 1 1 1) -> 1
(* 1 1) -> 1
(* 1) -> we want it to act as being equivalent to (* 1 1).
(*) -> same.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]