Floating point Arithmetic seems odd in Python

[Lasdjfk]

What do you think about this?

>>> trans = [{'debit':'50.6'},{'debit':'20.2'}]
>>> for row in trans:
    row['debit'] = float(row['debit'])
 
>>> trans
[{'debit': 50.600000000000001}, {'debit': 20.199999999999999}]
 

I Just want to convert some string to float but I get these weird numbers. Is it a bug in Python or am I doing something wrong?

[bvdet]

What do you think about this?

>>> trans = [{'debit':'50.6'},{'debit':'20.2'}]
>>> for row in trans:
    row['debit'] = float(row['debit'])
 
>>> trans
[{'debit': 50.600000000000001}, {'debit': 20.199999999999999}]
 

I Just want to convert some string to float but I get these weird numbers. Is it a bug in Python or am I doing something wrong?

You are doing nothing wrong, nor is there a bug in Python. Floating point numbers cannot always be represented with 100% accuracy. When testing for equality, it is necessary to compare the numbers to a very small one. Here is an example:

....def equiv(self, other, epsilon = 0.000001):
        '''
        Compares two vectors, returns a tuple of 1, 0, or -1 values
        Interactive example:
        >>> Point(1,1,5).equiv(Point(2,0,5))
        (-1, 1, 0)
        >>> 
        '''
        def comp(x,y):
            if abs(x-y) < epsilon: return 0
            elif x > y: return 1
            else: return -1
        return tuple(map(comp, self, other))

[bartonc]

What do you think about this?

>>> trans = [{'debit':'50.6'},{'debit':'20.2'}]
>>> for row in trans:
    row['debit'] = float(row['debit'])
 
>>> trans
[{'debit': 50.600000000000001}, {'debit': 20.199999999999999}]
 

I Just want to convert some string to float but I get these weird numbers. Is it a bug in Python or am I doing something wrong?

If you take it down to the "ones-and-zeros" where floating point numbers (and every thing else) must eventually be represented, you'll find that there is no way to store 20.2 precisely. Given the number of bits available, that's a pretty good approximation, though. Going the other way (float to text) is handled correctly:

>>> a = 20.2
>>> a
20.199999999999999
>>> "%.2f" %a
'20.20'
>>> 

[Lasdjfk]

Thanks a lot bartonc and bvdet!

I was afraid I would have to rip up my whole code to work around this ;-). Interesting with that binary-thing. Never thought about that before.

Hahaha, just found the python-docs:
[HTML]Note that this is in the very nature of binary floating-point: this is not a bug in Python, and it is not a bug in your code either.
[/HTML]

Guess I should have looked there first, if I knew what I was looking for :-).

[bartonc]

Thanks a lot bartonc and bvdet!

I was afraid I would have to rip up my whole code to work around this ;-). Interesting with that binary-thing. Never thought about that before.

Hahaha, just found the python-docs:
[HTML]Note that this is in the very nature of binary floating-point: this is not a bug in Python, and it is not a bug in your code either.
[/HTML]

Guess I should have looked there first, if I knew what I was looking for :-).

Just thought that I'd add the link: B. Floating Point Arithmetic: Issues and Limitations

Thanks for supplying that quote from the docs.

[elcron]

A wrapper class could fix your representation problem. Though you would have to create instances of it rather than float.

class Decimal(float):
    def __repr__(self):
        return '%.2f' %(self)
 

[bartonc]

A wrapper class could fix your representation problem. Though you would have to create instances of it rather than float.

class Decimal(float):
    def __repr__(self):
        return '%.2f' %(self)
 

Nice thought, but there is a name clash there...

>>> from decimal import Decimal

[bartonc]

Nice thought, but there is a name clash there...

>>> from decimal import Decimal

And here's that link:5.6 decimal -- Decimal floating point arithmetic[HTML]New in version 2.4.

The decimal module provides support for decimal floating point arithmetic. It offers several advantages over the float() datatype:

* Decimal numbers can be represented exactly. In contrast, numbers like 1.1 do not have an exact representation in binary floating point. End users typically would not expect 1.1 to display as 1.1000000000000001 as it does with binary floating point.[/HTML]