Re: (*) -> 1

[Óscar Fuentes]

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.