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

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

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

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> 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.

I'm not sure I'm a fan of this.  Is this common in other languages?

Why not just introduce a new constant `infinity'?  One could then write
`(- infinity)' to get negative infinity.

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

What would the calls look like?

Best regards,
Stefan Kangas

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

[Andy Moreton]

On Sat 01 Aug 2020, Michael Heerdegen 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, 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.

A zero argument call to these functions is more likely to be a bug,
which this proposal would make harder to locate.

If the read syntax is obscure, perhaps it would be better to add new
constants e.g. `posinf' and `neginf'.

    AndyM

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

[Mattias Engdegård]

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.

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

[Drew Adams]

FWIW, Common Lisp requires at least one arg:

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

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

[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.

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> 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.

There's `float-pi', so perhaps `float-infinity' would make sense?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

Michael Heerdegen <michael_heerdegen@web.de> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

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

[Michael Heerdegen]

Dmitry Alexandrov <dag@gnui.org> 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.

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

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> 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

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

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

Michael Heerdegen <michael_heerdegen@web.de> wrote:
> Dmitry Alexandrov <dag@gnui.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> 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.

I think the conclusion here was that there was limited enthusiasm for
doing this (since it's more likely that (max) is a programming error
instead of a way to write -1.0e+INF).  And there didn't seem to be much
enthusiasm for defining constants for this, either, since we have the
1.0e+INF syntax, as hard as that is to type.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no