5 ms·

Python's float makes me want to smoke crack

12 points by illumen 17y ago

bluetech 17y ago
Python 3.1 changes the way floats are converted to strings. See http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-language-changes http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-lang...
Sephr 17y ago
I still would prefer floats as default instead of decimals. What should be fixed is how you have to convert a float to a string to then convert it to a decimal.
- jerf 17y ago
  Python is trying to tell you something. By the time you've got a float, it's too late to turn it into a Decimal. The operation doesn't make sense. You can argue about the details, but a floating point number doesn't represent a number, it represents a numeric range, the exemplar of an infinite set of values that would map to the same float if converted to a float. When you ask to turn a float into a Decimal, which element of the range the float represents are you trying to turn into an exact Decimal? The operation is ill-defined. All hacking it up with a string does is convince Python that you actually mean that exact number, but you're hacking. Either convert where you got that "float" directly into Decimal (where Python can't tell enough to know where the number came from), or deal with the fact that you are cheating and it may bite you in the future. So, no, the correct solution is not to "convert the input into a float, then convert that into a string, then convert that to a Decimal"; the correct solution is to make sure you never pass through float in the first place. Unless you're loading a binary file specified as containing IEEE-754 floats, you probably didn't actually have to cut through the float stage. Anything other than the correct solution should be expected to be annoying and blow up at random times. Floats are treacherous little bastards, and all attempts to paper over that fact will lead to grief.
duskwuff 17y ago
All makes sense to me. The first "silliness" is because float's __repr__ is a little different from its __str__. This is because str() is supposed to return a user-friendly representation (e.g, fewer decimal places) whereas repr() is supposed to return something that's an exact representation of the value (e.g, enough decimal places to replicate the bit pattern). Decimal not converting from floats is also intentional. While it's possible to represent any float as a decimal, chances are that any randomly chosen float will be a very long and ugly decimal. Decimal isn't a float replacement - if you're basing your whole argument on the idea that decimal should be the default numeric type, you don't really understand the difference.
erlanger 17y ago
Crack is not good for you.
- cellis 17y ago
  Do you have some data to back this up? Just sayin :)
cortesi 17y ago
This chap has no idea what he's talking about - there are very good reasons why the Python interfaces are designed the way they are. The real rofl moment is in the comments when he kindly recommends that Python should "try to keep up and move on to more dense numbers"... like 64 bit ints and decimals. I mean... wha??

12 points by illumen 17y ago

Python 3.1 changes the way floats are converted to strings. See http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-language-changes http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-lang...

Sephr 17y ago

I still would prefer floats as default instead of decimals. What should be fixed is how you have to convert a float to a string to then convert it to a decimal.

jerf 17y ago
Python is trying to tell you something. By the time you've got a float, it's too late to turn it into a Decimal. The operation doesn't make sense. You can argue about the details, but a floating point number doesn't represent a number, it represents a numeric range, the exemplar of an infinite set of values that would map to the same float if converted to a float. When you ask to turn a float into a Decimal, which element of the range the float represents are you trying to turn into an exact Decimal? The operation is ill-defined. All hacking it up with a string does is convince Python that you actually mean that exact number, but you're hacking. Either convert where you got that "float" directly into Decimal (where Python can't tell enough to know where the number came from), or deal with the fact that you are cheating and it may bite you in the future. So, no, the correct solution is not to "convert the input into a float, then convert that into a string, then convert that to a Decimal"; the correct solution is to make sure you never pass through float in the first place. Unless you're loading a binary file specified as containing IEEE-754 floats, you probably didn't actually have to cut through the float stage. Anything other than the correct solution should be expected to be annoying and blow up at random times. Floats are treacherous little bastards, and all attempts to paper over that fact will lead to grief.

duskwuff 17y ago

All makes sense to me. The first "silliness" is because float's __repr__ is a little different from its __str__. This is because str() is supposed to return a user-friendly representation (e.g, fewer decimal places) whereas repr() is supposed to return something that's an exact representation of the value (e.g, enough decimal places to replicate the bit pattern). Decimal not converting from floats is also intentional. While it's possible to represent any float as a decimal, chances are that any randomly chosen float will be a very long and ugly decimal. Decimal isn't a float replacement - if you're basing your whole argument on the idea that decimal should be the default numeric type, you don't really understand the difference.

erlanger 17y ago

Crack is not good for you.

cellis 17y ago
Do you have some data to back this up? Just sayin :)

cortesi 17y ago

This chap has no idea what he's talking about - there are very good reasons why the Python interfaces are designed the way they are. The real rofl moment is in the comments when he kindly recommends that Python should "try to keep up and move on to more dense numbers"... like 64 bit ints and decimals. I mean... wha??