[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (*) -> 1
From: |
Óscar Fuentes |
Subject: |
Re: (*) -> 1 |
Date: |
Wed, 18 Jan 2023 15:07:10 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: (*) -> 1, (continued)
- Re: (*) -> 1, Óscar Fuentes, 2023/01/18
- RE: [External] : Re: (*) -> 1, Drew Adams, 2023/01/18
- Re: (*) -> 1, Michael Heerdegen, 2023/01/17
- Re: (*) -> 1, Michael Heerdegen, 2023/01/17
- Re: (*) -> 1, Óscar Fuentes, 2023/01/17
- Re: (*) -> 1, Michael Heerdegen, 2023/01/17
- Re: (*) -> 1, Óscar Fuentes, 2023/01/18
- Re: (*) -> 1, tomas, 2023/01/18
- Re: (*) -> 1, Óscar Fuentes, 2023/01/18
- Re: (*) -> 1, Michael Heerdegen, 2023/01/18
- Re: (*) -> 1,
Óscar Fuentes <=
- Re: (*) -> 1, Andreas Eder, 2023/01/18
- Re: (*) -> 1, Óscar Fuentes, 2023/01/18
- Re: (*) -> 1, Jean Louis, 2023/01/17
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, Emanuel Berg, 2023/01/17
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, Jean Louis, 2023/01/15
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, tomas, 2023/01/16
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, Jean Louis, 2023/01/16
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, Yuri Khan, 2023/01/16
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, Jean Louis, 2023/01/16
- Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?, Emanuel Berg, 2023/01/17