bug#42644: 28.0.50; Please let max and min accept zero arguments

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Michael Heerdegen

Hello,

I want to suggest to make the functions `max' and `min' accept zero
arguments, with

  (max) => negative infinity
  (min) => positive infinity

That would be mathematically consistent, and would offer an easier to
remember syntax to specify the infinities (at least for mathematicians).
I hate the read syntax suggested in the manual, I have to look it up
every single time.  Ironically, most of the time I use it it's the
initial value for a max or min number sequence folding.

`seq-max' and `seq-min' should also support it.

TIA,

Michael.


In GNU Emacs 28.0.50 (build 161, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2020-07-31 built on drachen
Repository revision: 26cf87416ffec74f4ffb05f652c927b75f5ee482
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid




Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Mattias Engdegård-2
That's funny, I was just thinking about whether to do anything about the byte-compiler raising an error when compiling (min) and (max), rather than just emitting a warning.

Extending min/max with ±Inf as identities is indeed attractive and would simplify some code by removing an edge or base case. The main argument against the extension is the worry that some errors would become hidden or handled inappropriately.

If you find ±1.0e+INF to be hard to remember -- you are not alone -- we could add the constants positive-infinity, negative-infinity, or just infinity.




Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Drew Adams
In reply to this post by Michael Heerdegen
FWIW, Common Lisp requires at least one arg:

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node124.html



Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Michael Heerdegen
In reply to this post by Michael Heerdegen
Hello to all,

> I want to suggest to make the functions `max' and `min' accept zero
> arguments
>
>   (max) => negative infinity
>   (min) => positive infinity

thanks for your comments.  More or less everyone seems to prefer the
introduction of constants instead.  I have no objections to solve my
"issue" (solely) in that way.  (And for `seq-min' and `seq-max' my
suggestion would also introduce the problem that the return value would
be undefinable if the given SEQUENCE is empty but a PREDICATE or KEY
function is specified).

Ok - how and where should we define such constant(s)?  I think I would
prefer Stefan's suggestion to introduce only one constant named
"infinity", for no strong reasons.

Thanks,

Michael.



Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Dmitry Alexandrov-2
In reply to this post by Michael Heerdegen
Michael Heerdegen <[hidden email]> wrote:
> I want to suggest to make the functions `max' and `min' accept zero
> arguments, with
>
>   (max) => negative infinity
>   (min) => positive infinity
>
> That would be mathematically consistent

For _current_ their implementation.

As you know, like most functions that operate on numbers, ‘min’ and ‘max’ really accept _different_ types of objects: integers ‘fixnums’, IEEE-754 inexact numbers ‘flonums’, and context-aware buffer positions ‘markers’.  Return value is coerced to the type that is sort of common denominator of types of arguments.  But what should be used if there are none?  Whatever can be the most minimal / maximal now?

But once upon a time Emacs did not support flonums at all, so using that rule the choice for an identity value for ‘min’ (if we reject the idea to return some marker in some buffer as an absurd) was most-positive-fixnum.

Note, how this is unlike choosing that (+) ⇒ 0 and (*) ⇒ 1, than 0.0 and 1.0 resp., because (= 0 0.0) and (= 1 1.0) while, of course, (/= +1.0e+INF most-positive-fixnum).  And imagine what a mess it would be, if someone indeed had done this?

In short, I believe, other languages (including kindred ones: Scheme and Common Lisp) are absolutely right in treating (max) and (min) as errors.

> and would offer an easier to remember syntax to specify the infinities (at least for mathematicians).  I hate the read syntax suggested in the manual, I have to look it up every single time.

What reader syntax would you prefer?  If Schemeʼs +inf.0 and -inf.0, then note, that they are valid symbols in Elisp.  That is, you can perfectly do:

        (defconst +inf.0 +1.0e+INF)
        (defconst -inf.0 -1.0e+INF)

> (at least for mathematicians)

As for that regard, whatʼs wrong with, (/ +1.0 0) and (/ -1.0 0)?


BTW, I am surprised to hear, that IEEE-754-infinities are so much used in Elisp.

signature.asc (253 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Michael Heerdegen
Dmitry Alexandrov <[hidden email]> writes:

> What reader syntax would you prefer?

I'm not criticizing the current syntax for the infinities.  It's just
hard to remember them.

> As for that regard, whatʼs wrong with, (/ +1.0 0) and (/ -1.0 0)?

Wow, that doesn't error?  It's hard to find a mathematical
interpretation in which this makes any sense.  IMHO much more weird than
allowing zero args for `max' and `min'.

Michael.



Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Stefan Kangas
Michael Heerdegen <[hidden email]> writes:

> > As for that regard, whatʼs wrong with, (/ +1.0 0) and (/ -1.0 0)?
>
> Wow, that doesn't error?  It's hard to find a mathematical
> interpretation in which this makes any sense.  IMHO much more weird than
> allowing zero args for `max' and `min'.

I guess this is related to IEEE-754.  I found an explanation here:

https://stackoverflow.com/questions/14682005/why-does-division-by-zero-in-ieee754-standard-results-in-infinite-value

Best regards,
Stefan Kangas



Reply | Threaded
Open this post in threaded view
|

bug#42644: 28.0.50; Please let max and min accept zero arguments

Dmitry Alexandrov-2
In reply to this post by Michael Heerdegen
Michael Heerdegen <[hidden email]> wrote:
> Dmitry Alexandrov <[hidden email]> writes:
>
>> What reader syntax would you prefer?
>
> I'm not criticizing the current syntax for the infinities.  It's just hard to remember them.

???

>> As for that regard, whatʼs wrong with, (/ +1.0 0) and (/ -1.0 0)?
>
> Wow, that doesn't error?

Thankfully, no.  So third-parties do not have to invent another numbers, like in some other languages:

        >>> 1 / 0.0
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        ZeroDivisionError: float division by zero
        >>> import numpy
        >>> 1 / numpy.float64(0.0)
        inf

> It's hard to find a mathematical interpretation in which this makes any sense.

Dunno.  It makes perfect natural sense to me.  Perhaps, mathematics is too mind-warping. :-)

Also, Iʼd better emphasised zero, not numerator, with explicit flonum notation.  I hope, writing the same thing another way would help to realise how obvious it is:

        (/ +1 0.0) ; ⇒ 1.0e+INF

signature.asc (253 bytes) Download Attachment