From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: =?utf-8?Q?=C3=93scar_Fuentes?= <ofv@wanadoo.es>
Newsgroups: gmane.emacs.help
Subject: Re: (*) -> 1
Date: Wed, 18 Jan 2023 15:07:10 +0100
Message-ID: <878ri09bsh.fsf@telefonica.net>
References: <CO6PR10MB5473E554BE84BF9CC2E9AF6DF3C69@CO6PR10MB5473.namprd10.prod.outlook.com>
 <Y8Yzh7xGQDCqRkpJ@protected.localdomain> <87sfg9kuya.fsf@web.de>
 <Y8bTBTvx4qiup1on@protected.localdomain> <87bkmxkpzg.fsf@web.de>
 <878ri1av5j.fsf@telefonica.net> <87ilh4kgqo.fsf@web.de>
 <87zgagakh5.fsf@telefonica.net> <87cz7cka06.fsf@web.de>
 <87v8l49t8w.fsf@telefonica.net> <Y8evxjuR1YQWW10L@tuxteam.de>
 <87h6wo9fjb.fsf@telefonica.net> <87edrsufdd.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="34009"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
To: help-gnu-emacs@gnu.org
Cancel-Lock: sha1:QTF3sW1ZQYwJ5qwHkG816EcmOcU=
Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 18 15:07:49 2023
Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>
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 <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>)
	id 1pI96T-0008dj-AO
	for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 15:07:49 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <help-gnu-emacs-bounces@gnu.org>)
	id 1pI963-0008VM-TH; Wed, 18 Jan 2023 09:07:23 -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 <geh-help-gnu-emacs@m.gmane-mx.org>)
 id 1pI962-0008Up-5m
 for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 09:07:22 -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 <geh-help-gnu-emacs@m.gmane-mx.org>)
 id 1pI960-0006iA-Ez
 for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 09:07:21 -0500
Original-Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <geh-help-gnu-emacs@m.gmane-mx.org>)
 id 1pI95w-0007xo-Tr
 for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 15:07:16 +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: -16
X-Spam_score: -1.7
X-Spam_bar: -
X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 <help-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-gnu-emacs>,
 <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/help-gnu-emacs>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-gnu-emacs>,
 <mailto:help-gnu-emacs-request@gnu.org?subject=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:142359
Archived-At: <http://permalink.gmane.org/gmane.emacs.help/142359>

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Even a programmer can't assume that associativity and commutativity
>> can be used on a long, finite, sum.
>
> As long as it's a sum, of course can a programmer assume that.

Of course not! Otherwise your numerical simulation can go very wrong :-)

(hint: numbers in computers are approximate, adding small numbers to
large numbers is a bad idea.)

>> But that's a digression. My point is that (+) and (+ n) are not
>> supported (or, better said, appreciated) because some mathematical
>> reason, but because they are as much convenient when writing macros as
>> they are silly on "normal" code. It's about making easy for the
>> programmer to do some mundane tasks, not about Mathematics.
>
> No - the result of "1" is surely related to mathematics.  It comes from
> the mathematical interpretation of the term (*) as empty product.

Sure.

> You can interpret it differently, but the convention is the same and
> there for the same reason as the same convention for the empty product
> in math.

Sure^2. I was talking about _why_ (*) and (* a) are supported in Elisp.
Once the language designer chose to support those expressions and
decided that they must return a number (instead of something else like a
partially applied function) the value they shall return comes from the
properties of the underlying operation, of course.