Re: [Emacs-diffs] master 37940b3: min and max now return one of their arguments

[Paul Eggert]

On 03/09/2017 08:10 AM, Eli Zaretskii wrote:
> > > Don't programmers
> > > assume in general that comparisons between values some of which are
> > > floats are always done after converting_all_  values to the
> > > floating-point representation?
> > No, and that hasn't been true for Emacs Lisp for quite some time. In
> > Emacs 25, (<= 10000000000000001 10000000000000000 1e16) returns the
> > mathematically-correct answer nil on a 64-bit GNU/Linux host even though
> > it would return t if all values were first converted to float.
> Not sure what that demonstrates

It demonstrates that historically Emacs has been inconsistent in this 
area. Sometimes it behaves as if it converts all values to 
floating-point, sometimes not. The example I gave is where Emacs 25 
returns the mathematically-correct answer even though converting all 
values to floating-point would return the mathematically-incorrect 
answer. There are other examples where Emacs 25 does the opposite.

> I get
>
>    (<= 10000000000000001 1e16) => t
>
> in Emacs 25.1 on a 64-bit GNU/Linux host.
Yes, and that's an example of the opposite. Emacs 25 is inconsistent, 
and this inconsistency leads to weirdnesses, e.g., it's possible for (<= 
A C) to be nil even though (<= A B C) is t, because the implementation 
of <= does not compare consistently. Programmers generally do not expect 
these weirdnesses, and the patches in master remove them by having Emacs 
use consistent comparisons.