Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #93425 > unrolled thread

Bug in floating point multiplication

Started bySteven D'Aprano <steve@pearwood.info>
First post2015-07-03 00:52 +1000
Last post2015-07-05 09:38 +0200
Articles 3 on this page of 23 — 16 participants

Back to article view | Back to comp.lang.python


Contents

  Bug in floating point multiplication Steven D'Aprano <steve@pearwood.info> - 2015-07-03 00:52 +1000
    Re: Bug in floating point multiplication Michael Poeltl <michael.poeltl@univie.ac.at> - 2015-07-02 17:10 +0200
    Re: Bug in floating point multiplication Chris Angelico <rosuav@gmail.com> - 2015-07-03 01:21 +1000
    Re: Bug in floating point multiplication Robin Becker <robin@reportlab.com> - 2015-07-02 16:24 +0100
    Re: Bug in floating point multiplication Paul Rubin <no.email@nospam.invalid> - 2015-07-02 08:26 -0700
      Re: Bug in floating point multiplication Chris Angelico <rosuav@gmail.com> - 2015-07-03 01:34 +1000
        Re: Bug in floating point multiplication Steven D'Aprano <steve@pearwood.info> - 2015-07-03 01:41 +1000
      Re: Bug in floating point multiplication Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-02 09:38 -0600
    Re: Bug in floating point multiplication Vincent Vande Vyvre <vincent.vande.vyvre@telenet.be> - 2015-07-02 17:15 +0200
    Re: Bug in floating point multiplication Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-02 09:28 -0600
    Re: Bug in floating point multiplication Robin Becker <robin@reportlab.com> - 2015-07-02 16:29 +0100
    Re: Bug in floating point multiplication Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-02 09:32 -0600
    Re: Bug in floating point multiplication Steven D'Aprano <steve@pearwood.info> - 2015-07-03 01:42 +1000
    Re: Bug in floating point multiplication duncan smith <buzzard@invalid.invalid> - 2015-07-02 17:08 +0100
    Re: Bug in floating point multiplication MRAB <python@mrabarnett.plus.com> - 2015-07-02 17:20 +0100
    Re: Bug in floating point multiplication Tim Chase <python.list@tim.thechases.com> - 2015-07-02 11:59 -0500
    Re: Bug in floating point multiplication Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2015-07-02 19:49 +0200
      Re: Bug in floating point multiplication Ned Deily <nad@acm.org> - 2015-07-02 22:07 -0700
        Re: Bug in floating point multiplication Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2015-07-03 18:27 +0200
    Re: Bug in floating point multiplication Laurent Pointal <laurent.pointal@free.fr> - 2015-07-02 23:12 +0200
    Re: Bug in floating point multiplication Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-07-03 16:13 +0100
    Re: Bug in floating point multiplication Laura Creighton <lac@openend.se> - 2015-07-05 00:54 +0200
    Re: Bug in floating point multiplication Peter Otten <__peter__@web.de> - 2015-07-05 09:38 +0200

Page 2 of 2 — ← Prev page 1 [2]


#93466

FromOscar Benjamin <oscar.j.benjamin@gmail.com>
Date2015-07-03 16:13 +0100
Message-ID<mailman.275.1435936461.3674.python-list@python.org>
In reply to#93425
On 2 July 2015 at 18:29, Jason Swails <jason.swails@gmail.com> wrote:
>
> As others have suggested, this is almost certainly a 32-bit vs. 64-bit
> issue.  Consider the following C program:
>
> // maths.h
> #include <math.h>
> #include <stdio.h>
>
> int main() {
>     double x;
>     int i;
>     x = 1-pow(0.5, 53);
>
>     for (i = 1; i < 1000000; i++) {
>         if ((int)(i*x) == i) {
>             printf("%d\n", i);
>             break;
>         }
>     }
>
>     return 0;
> }
>
> For the most part, this should be as close to an exact transliteration of
> your Python code as possible.
>
> Here's what I get when I try compiling and running it on my 64-bit (Gentoo)
> Linux machine with 32-bit compatible libs:
>
> swails@batman ~/test $ gcc maths.c
> swails@batman ~/test $ ./a.out
> swails@batman ~/test $ gcc -m32 maths.c
> swails@batman ~/test $ ./a.out
> 2049

I was unable to reproduce this on my system. In both cases the loops
run to completion. A look at the assembly generated by gcc shows that
something different goes on there though.

The loop in the 64 bit one (in the main function) looks like:

$ objdump -d a.out | less
...
400555:  pxor   %xmm0,%xmm0
400559:  cvtsi2sdl -0xc(%rbp),%xmm0
40055e:  mulsd  -0x8(%rbp),%xmm0
400563:  cvttsd2si %xmm0,%eax
400567:  cmp    -0xc(%rbp),%eax
40056a:  jne    400582 <main+0x4c>
40056c:  mov    -0xc(%rbp),%eax
40056f:  mov    %eax,%esi
400571:  mov    $0x400624,%edi
400576:  mov    $0x0,%eax
40057b:  callq  400410 <printf@plt>
400580:  jmp    40058f <main+0x59>
400582:  addl   $0x1,-0xc(%rbp)
400586:  cmpl   $0xf423f,-0xc(%rbp)
40058d:  jle    400555 <main+0x1f>
...

Where is the 32 bit one looks like:

$ objdump -d a.out.32 | less
...
 804843e:  fildl  -0x14(%ebp)
 8048441:  fmull  -0x10(%ebp)
 8048444:  fnstcw -0x1a(%ebp)
 8048447:  movzwl -0x1a(%ebp),%eax
 804844b:  mov    $0xc,%ah
 804844d:  mov    %ax,-0x1c(%ebp)
 8048451:  fldcw  -0x1c(%ebp)
 8048454:  fistpl -0x20(%ebp)
 8048457:  fldcw  -0x1a(%ebp)
 804845a:  mov    -0x20(%ebp),%eax
 804845d:  cmp    -0x14(%ebp),%eax
 8048460:  jne    8048477 <main+0x5c>
 8048462:  sub    $0x8,%esp
 8048465:  pushl  -0x14(%ebp)
 8048468:  push   $0x8048520
 804846d:  call   80482f0 <printf@plt>
 8048472:  add    $0x10,%esp
 8048475:  jmp    8048484 <main+0x69>
 8048477:  addl   $0x1,-0x14(%ebp)
 804847b:  cmpl   $0xf423f,-0x14(%ebp)
 8048482:  jle    804843e <main+0x23>
...

So the 64 bit one is using SSE instructions and the 32-bit one is
using x87. That could explain the difference you see at the C level
but I don't see it on this CPU (/proc/cpuinfo says Intel(R) Core(TM)
i5-3427U CPU @ 1.80GHz).

--
Oscar

[toc] | [prev] | [next] | [standalone]


#93495

FromLaura Creighton <lac@openend.se>
Date2015-07-05 00:54 +0200
Message-ID<mailman.294.1436050467.3674.python-list@python.org>
In reply to#93425
In a message of Fri, 03 Jul 2015 00:52:55 +1000, "Steven D'Aprano" writes:
>Despite the title, this is not one of the usual "Why can't Python do
>maths?" "bug" reports.
>
>Can anyone reproduce this behaviour? If so, please reply with the version of
>Python and your operating system. Printing sys.version will probably do.
>
>
>x = 1 - 1/2**53
>assert x == 0.9999999999999999
>for i in range(1, 1000000):
>    if int(i*x) == i:
>        print(i); break
>
>
>Using Jython and IronPython, the loop runs to completion. That is the
>correct behaviour, or so I am lead to believe. Using Python 2.6, 2.7 and
>3.3 on Centos and Debian, it prints 2049 and breaks. That should not
>happen. If you can reproduce that (for any value of i, not necessarily
>2049), please reply.
>
>See also http://bugs.python.org/issue24546 for more details.
>
>
>
>-- 
>Steven

PyPy says:
Python 2.7.9 (2.5.1+dfsg-1, Mar 27 2015, 19:45:43)
[PyPy 2.5.1 with GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> x = 1 - 1/2**53
>>>> assert x == 0.9999999999999999
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError
>>>> for i in range(1, 1000000):
....     if int(i*x) == i:
....             print(i); break
....             
.... 
1
>>>> 

So the loop terminates, but there is an Assertion Error.  Did you want that?

Laura

[toc] | [prev] | [next] | [standalone]


#93504

FromPeter Otten <__peter__@web.de>
Date2015-07-05 09:38 +0200
Message-ID<mailman.302.1436081928.3674.python-list@python.org>
In reply to#93425
Laura Creighton wrote:

> In a message of Fri, 03 Jul 2015 00:52:55 +1000, "Steven D'Aprano" writes:
>>Despite the title, this is not one of the usual "Why can't Python do
>>maths?" "bug" reports.
>>
>>Can anyone reproduce this behaviour? If so, please reply with the version
>>of Python and your operating system. Printing sys.version will probably
>>do.
>>
>>
>>x = 1 - 1/2**53
>>assert x == 0.9999999999999999
>>for i in range(1, 1000000):
>>    if int(i*x) == i:
>>        print(i); break
>>
>>
>>Using Jython and IronPython, the loop runs to completion. That is the
>>correct behaviour, or so I am lead to believe. Using Python 2.6, 2.7 and
>>3.3 on Centos and Debian, it prints 2049 and breaks. That should not
>>happen. If you can reproduce that (for any value of i, not necessarily
>>2049), please reply.
>>
>>See also http://bugs.python.org/issue24546 for more details.
>>
>>
>>
>>--
>>Steven
> 
> PyPy says:
> Python 2.7.9 (2.5.1+dfsg-1, Mar 27 2015, 19:45:43)
> [PyPy 2.5.1 with GCC 4.9.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>>> x = 1 - 1/2**53
>>>>> assert x == 0.9999999999999999
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AssertionError
>>>>> for i in range(1, 1000000):
> ....     if int(i*x) == i:
> ....             print(i); break
> ....
> ....
> 1
>>>>> 
> 
> So the loop terminates, but there is an Assertion Error.  Did you want
> that?

No. Steven's environment implies

from __future__ import division

which he forgot to mention in the original post:

>>>> x = 1-1/2**53
>>>> x
1
>>>> from __future__ import division
>>>> x = 1-1/2**53
>>>> x
0.9999999999999999


[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python


csiph-web