GNU bug report logs - #42597
27.1; (+ -0.0) returns +0.0 when compiled

Previous Next

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

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

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; (+ -0.0) returns +0.0 when compiled
Date: Wed, 29 Jul 2020 14:07:32 +0200

Unary +, *, min and max, all of which should be identity for numbers, convert -0.0 to +0.0 when byte-compiled:

(defun f (x) (+ x))
(f -0.0)
=> -0.0
(byte-compile 'f)
(f -0.0)
=> 0.0

The reason is that byte-compile-associative transforms (+ x), (* x), (min x) and (max x) into (+ x 0).

No patch yet (sorry!) but I'm not sure what would be the best way to go about it. Some possibilities:

A. Use a full 1-argument call, like (+ x). This is more expensive (about 1.8×) since the general function call mechanism has to be used.
B. Use (* x 1) instead; this appears to work. This is also more expensive (1.6×); not sure why.
C. Add a new byte-op. Fast but probably overkill.

Better suggestions welcome!

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

From: Alan Mackenzie <acm <at> muc.de>
To: 42597 <at> debbugs.gnu.org
Subject: Re: bug#42597: 27.1; (+ -0.0) returns +0.0 when compiled (fwd)
Date: Wed, 29 Jul 2020 15:41:27 +0200 (CEST)

[Message part 1 (text/plain, inline)]

Hello, Mattias.

In article <mailman.247.1596026464.2739.bug-gnu-emacs <at> gnu.org> you wrote:
> Unary +, *, min and max, all of which should be identity for numbers,
> convert -0.0 to +0.0 when byte-compiled:

They convert what?

> (defun f (x) (+ x))
> (f -0.0)
> => -0.0
> (byte-compile 'f)
> (f -0.0)
> => 0.0

> The reason is that byte-compile-associative transforms (+ x), (* x),
> (min x) and (max x) into (+ x 0).

> No patch yet (sorry!) but I'm not sure what would be the best way to go
> about it. Some possibilities:

> A. Use a full 1-argument call, like (+ x). This is more expensive
>    (about 1.8×) since the general function call mechanism has to be used.
> B. Use (* x 1) instead; this appears to work. This is also more
>    expensive (1.6×); not sure why.
> C. Add a new byte-op. Fast but probably overkill.

> Better suggestions welcome!

This is an example of what happens when ignorant people rule the roost.
-0.0 and +0.0 are identically the same thing.  It should not take a
degree in mathematics (which I have) to realise this.  When you put
mathematical nonsense into <whatever thing is producing -0.0> you cannot
help but get nonsense back out.

0.0 does not need two different names.  It can do nothing but produce
confusion, what has clearly happened here at whatever level.

So my suggestion D. would be: Eliminate "-0.0" from Emacs Lisp.  If this
is not possible for whatever reason, then E. Do nothing.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 42597 <at> debbugs.gnu.org
Subject: Re: bug#42597: 27.1; (+ -0.0) returns +0.0 when compiled (fwd)
Date: Wed, 29 Jul 2020 18:32:45 +0000

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Mattias.
>
> In article <mailman.247.1596026464.2739.bug-gnu-emacs <at> gnu.org> you wrote:
>> Unary +, *, min and max, all of which should be identity for numbers,
>> convert -0.0 to +0.0 when byte-compiled:
>
> They convert what?
>
>> (defun f (x) (+ x))
>> (f -0.0)
>> => -0.0
>> (byte-compile 'f)
>> (f -0.0)
>> => 0.0
>
>> The reason is that byte-compile-associative transforms (+ x), (* x),
>> (min x) and (max x) into (+ x 0).
>
>> No patch yet (sorry!) but I'm not sure what would be the best way to go
>> about it. Some possibilities:
>
>> A. Use a full 1-argument call, like (+ x). This is more expensive
>>    (about 1.8×) since the general function call mechanism has to be used.
>> B. Use (* x 1) instead; this appears to work. This is also more
>>    expensive (1.6×); not sure why.
>> C. Add a new byte-op. Fast but probably overkill.
>
>> Better suggestions welcome!
>
> This is an example of what happens when ignorant people rule the roost.
> -0.0 and +0.0 are identically the same thing.  It should not take a
> degree in mathematics (which I have) to realise this.  When you put
> mathematical nonsense into <whatever thing is producing -0.0> you cannot
> help but get nonsense back out.
>
> 0.0 does not need two different names.  It can do nothing but produce
> confusion, what has clearly happened here at whatever level.
>
> So my suggestion D. would be: Eliminate "-0.0" from Emacs Lisp.  If this
> is not possible for whatever reason, then E. Do nothing.

For completeness I'd like to link what is prescribed on that for CL:

<http://clhs.lisp.se/Body/f_eq_sle.htm>

"
Notes:

= differs from eql in that (= 0.0 -0.0) is always true, because =
compares the mathematical values of its operands, whereas eql compares
the representational values, so to speak.
"

  Andrea

-- 
akrl <at> sdf.org

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 42597 <at> debbugs.co.uk
Subject: Re: bug#42597: 27.1; (+ -0.0) returns +0.0 when compiled
Date: Mon, 3 Aug 2020 17:36:03 +0200

[Message part 1 (text/plain, inline)]

29 juli 2020 kl. 15.35 skrev Alan Mackenzie <acm <at> muc.de>:

> This is an example of what happens when ignorant people rule the roost.
> -0.0 and +0.0 are identically the same thing.  It should not take a
> degree in mathematics (which I have) to realise this.  When you put
> mathematical nonsense into <whatever thing is producing -0.0> you cannot
> help but get nonsense back out.

Thanks Alan -- there are good arguments both for and against negative zero and I would happily discuss them over a little glass of something once it is possible to meet in person again. Now we don't have much choice since IEEE-754 is what it is and we should have very strong reasons for making changes that conflict with that standard.

At the very least we should be consistent. The effort is small enough (first patch below, I went with the (* x 1) variant).

The code did contain a fair amount of obsolete and/or incorrect comments and decisions, some relating to bug#1334 which is no longer relevant (Emacs didn't have bignums at the time). Today, the N-arg semantics of +, - (except for N=1), *, min and max (but notably not /) are equivalent to the corresponding left-folds of binary operations, which helps a lot. The second patch cleans up and improves optimisation for arithmetic operations generally.

[0001-Fix-byte-compilation-of-0.0-bug-42597.patch (application/octet-stream, attachment)]

[0002-Clean-up-and-improve-compilation-of-arithmetic-opera.patch (application/octet-stream, attachment)]

Message #21 received at 42597-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 42597-done <at> debbugs.co.uk
Subject: Re: bug#42597: 27.1; (+ -0.0) returns +0.0 when compiled
Date: Fri, 7 Aug 2020 10:50:19 +0200

No immediate objections at least; patches pushed to master.

Previous Next

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