GNU bug report logs - #42644
28.0.50; Please let max and min accept zero arguments

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Sat, 1 Aug 2020 06:31:01 UTC

Severity: wishlist

Tags: wontfix

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42644 in the body.
You can then email your comments to 42644 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 01 Aug 2020 06:31:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 01 Aug 2020 06:31:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Please let max and min accept zero arguments
Date: Sat, 01 Aug 2020 08:30:42 +0200
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 01 Aug 2020 10:03:02 GMT) Full text and rfc822 format available.

Message #8 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sat, 1 Aug 2020 03:02:44 -0700
Michael Heerdegen <michael_heerdegen <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 01 Aug 2020 10:22:01 GMT) Full text and rfc822 format available.

Message #11 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: 42644 <at> debbugs.gnu.org
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>
Subject: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sat, 1 Aug 2020 12:21:51 +0200
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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 01 Aug 2020 10:23:02 GMT) Full text and rfc822 format available.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sat, 01 Aug 2020 11:21:44 +0100
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 01 Aug 2020 16:32:01 GMT) Full text and rfc822 format available.

Message #17 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 42644 <at> debbugs.gnu.org
Subject: RE: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sat, 1 Aug 2020 09:31:07 -0700 (PDT)
FWIW, Common Lisp requires at least one arg:

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 01 Aug 2020 23:35:01 GMT) Full text and rfc822 format available.

Message #20 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sun, 02 Aug 2020 01:34:07 +0200
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sun, 02 Aug 2020 04:04:01 GMT) Full text and rfc822 format available.

Message #23 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sun, 02 Aug 2020 06:02:56 +0200
Michael Heerdegen <michael_heerdegen <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sun, 02 Aug 2020 06:44:01 GMT) Full text and rfc822 format available.

Message #26 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Alexandrov <dag <at> gnui.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sun, 02 Aug 2020 09:43:25 +0300
[Message part 1 (text/plain, inline)]
Michael Heerdegen <michael_heerdegen <at> 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.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Mon, 03 Aug 2020 02:09:02 GMT) Full text and rfc822 format available.

Message #29 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Dmitry Alexandrov <dag <at> gnui.org>
Cc: 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Mon, 03 Aug 2020 04:08:27 +0200
Dmitry Alexandrov <dag <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Mon, 03 Aug 2020 11:06:02 GMT) Full text and rfc822 format available.

Message #32 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Dmitry Alexandrov <dag <at> gnui.org>, 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Mon, 3 Aug 2020 13:05:37 +0200
Michael Heerdegen <michael_heerdegen <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Mon, 03 Aug 2020 17:12:02 GMT) Full text and rfc822 format available.

Message #35 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Alexandrov <dag <at> gnui.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Mon, 03 Aug 2020 20:11:25 +0300
[Message part 1 (text/plain, inline)]
Michael Heerdegen <michael_heerdegen <at> web.de> wrote:
> Dmitry Alexandrov <dag <at> 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
[signature.asc (application/pgp-signature, inline)]

Severity set to 'wishlist' from 'normal' Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Thu, 13 Aug 2020 00:06:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42644; Package emacs. (Sat, 12 Feb 2022 08:10:01 GMT) Full text and rfc822 format available.

Message #40 received at 42644 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 42644 <at> debbugs.gnu.org
Subject: Re: bug#42644: 28.0.50; Please let max and min accept zero arguments
Date: Sat, 12 Feb 2022 09:09:40 +0100
Michael Heerdegen <michael_heerdegen <at> 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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 12 Feb 2022 08:10:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 42644 <at> debbugs.gnu.org and Michael Heerdegen <michael_heerdegen <at> web.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 12 Feb 2022 08:10:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 12 Mar 2022 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 39 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.