[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [Emacs-diffs] master 37940b3: min and max now return one of their arguments
Date: Thu, 9 Mar 2017 09:45:47 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]