123.4+2=125.40000000000001 
Author Message
 123.4+2=125.40000000000001

Quote:
>>> 123.4+2

125.40000000000001   # is this OK?

Quote:
>>> print 123.4+2
125.4

On my calculator: 123.4+2 = 125.4 !?
I am using python 1.6a2

Peter



Sun, 08 Dec 2002 03:00:00 GMT  
 123.4+2=125.40000000000001

Quote:

> >>> 123.4+2
> 125.40000000000001   # is this OK?
> >>> print 123.4+2
> 125.4

> On my calculator: 123.4+2 = 125.4 !?
> I am using Python 1.6a2

From http://www.python.org/1.6/

  The repr() of floating point numbers now gives full (17-digit)
  precision. This means that a number like 8.1 (which cannot be
  represented exactly in binary) will show up as 8.0999999999999996 when
  displayed using repr(). This shouldn't break any code but it may
  confuse users, especially since the interactive shell uses repr() to
  display all floating point results. Use str() or explicit precision in
  string format (e.g. "%.12g" % x) to see the the more familiar, rounded
  form.

Cut-n-paste'ly y'rs,

        - Ruud de Rooij.
--



Sun, 08 Dec 2002 03:00:00 GMT  
 123.4+2=125.40000000000001

Quote:

> >>> 123.4+2
> 125.40000000000001   # is this OK?
> >>> print 123.4+2
> 125.4

Short answer: This is the way it is.

Long answer:
It has to do with

1) Representation of floating point numbers internally
2) The difference between __repr__ and __str__

Point 1 ist that floating point numbers are not exact. Lots of people can
explain this better than me. Search deja, the answer is out there!

Point 2 is that print uses the __str__ method of an object to get the
printable string, but the interactive interpreter uses __repr__. __str__
does the rounding, __repr__ doesn't. Again, many others probably explain
this better than me. I could even be wrong, strange as it might seem!
Once again, search deja [1].

Quote:
> On my calculator: 123.4+2 = 125.4 !?

In fact, this probably isn't true. It's just that your calculator rounds
the answer before handing it to you, just like print. Maybe. I should
probably change my name to Search Deja... :)

Also note that there has been a lot of discussion on this topic here, and
that the behavior might change in a later version of python.

HTH,
  Kalle Svensson

[1] You might answer "No, you get eye cancer from looking at Deja."
    To this I have no reply. Just get a good health insurance. :)



Sun, 08 Dec 2002 03:00:00 GMT  
 123.4+2=125.40000000000001

Quote:

> >>> 123.4+2
> 125.40000000000001   # is this OK?
> >>> print 123.4+2
> 125.4

> On my calculator: 123.4+2 = 125.4 !?

Because your calculator works with a decimal representation of
numbers, whereas Python (and the vast majority of other programming
languages) uses a binary representation. In binary, the result of your
calculation has an infinite number of digits (like 1./3. has in
decimal) and cannot be represented exactly in a computer. That causes
the effect you observe.
--
-------------------------------------------------------------------------------

Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


Sun, 08 Dec 2002 03:00:00 GMT  
 123.4+2=125.40000000000001


Quote:
>> On my calculator: 123.4+2 = 125.4 !?

KS> In fact, this probably isn't true. It's just that your calculator rounds
KS> the answer before handing it to you, just like print. Maybe. I should
KS> probably change my name to Search Deja... :)

I think calculators use decimal representation internally, so they don't
get this kind of error. Of course this introduces errors in other cases.
--

URL: http://www.cs.uu.nl/~piet [PGP]



Sun, 08 Dec 2002 03:00:00 GMT  
 123.4+2=125.40000000000001

Quote:

> >>> 123.4+2
> 125.40000000000001   # is this OK?
> >>> print 123.4+2
> 125.4

> On my calculator: 123.4+2 = 125.4 !?
> I am using Python 1.6a2

FWIW, on my Python:

Quote:
>>> 123.4
123.40000000000001
>>> 0.4

0.40000000000000002

This isn't surprising, really, given that floats are represented in
base 2; floats are "really" rationals of the form M*(2**N) where M and
N are (bounded) integers, and 0.4 is 0.011001100110011001100110... in
binary.

Cheers,
M.

--
  There are 'infinite' number of developed artifacts and one cannot
  develop appreciation  for them all.  It would be all right to not
  understand something, but it would be imbecilic to put judgements
  on things one don't understand.               -- Xah, comp.lang.lisp



Sun, 08 Dec 2002 03:00:00 GMT  
 123.4+2=125.40000000000001

Quote:


> > >>> 123.4+2
> > 125.40000000000001   # is this OK?
> > >>> print 123.4+2
> > 125.4

> > On my calculator: 123.4+2 = 125.4 !?

> Because your calculator works with a decimal representation of
> numbers, whereas Python (and the vast majority of other programming
> languages) uses a binary representation. In binary, the result of your
> calculation has an infinite number of digits (like 1./3. has in
> decimal) and cannot be represented exactly in a computer. That causes
> the effect you observe.

Python uses C's "double" type, which on almost all modern machines uses
the IEEE format.  Omiting tons of neat details, IEEE double expresses
values as:

2^n * m/2^53

where m is unsigned between 0 and 2^53-1.

.4 cannot be expressed precisely in the above fraction; in base two .4
is a "repeating becimal"

--
Adam DePrince - firstname at lastname dot net, all in lowercase



Thu, 26 Dec 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. 123 .WKS format source - 123.prg (1/1)

2. Passing data by means of dde in clarion 4 to lotus 123

3. 123 password

4. 123 terminal server

5. Lotus 123/Novell/Clipper problem

6. ObjRexx v2.1 OLE interface to Lotus 123

7. SysFileDelete(filename) rc = 123

8. VX-REXX DDE to 123 r2.1 for OS/2

9. RC 123 in ObjREXX

10. Scheme Digest V4 #123

11. wanted: sample source for lotus 123 style character mode menus

12. ring 0 to ring 123

 

 
Powered by phpBB® Forum Software