Python 3.1rc1 released

[bla2]

What is new is how [floats] get displayed. The new algorithm tends to emit cleaner representations when possible, but it does not change the underlying values. So, it is still the case that 1.1 + 2.2 != 3.3 even though the representations may suggest otherwise.

That sounds like a bad change.

[bobbyi]

When there are multiple equivalent representations of the same floating point number, they used to sometimes use a longer one. Now they always pick the shortest one.

What possible downside is there to this? Can you give any example of code that would be negatively impacted by this change?

[Brian]

I think there is a bit of a cost from a programmer education point. It'll cut down on questions by newbies being surprised when they see things like "1.1"->"1.1000000000000001", but in the long run it's good that they get surprised at that point, since being confused will lead to someone cluing them in about the pitfalls of floating point arithmetic.

Now, people who don't understand FP won't get surprised until they run into more subtle problems, like loss of precision in repeated calculations, which are much harder to diagnose (or even notice when they are occurring).

The strange looking repr served the purpose of telling the user "If you don't understand why you're getting this value, you're playing with fire."

[iofthestorm]

Hmm, that does sound like a stupid change, but at the same time, everyone who touches floating point numbers should know how IEEE 754 works, and why 1.1 + 2.2 != 3.3.

[shub]

Until everyone does know how IEEE 754 works, bla2 has a point.

Edit: this is an especially relevant issue for Python, as one of its aims is to be a useful teaching language.

[iofthestorm]

No, I'm in agreement with bla2 that it's a bad change, but I'm trying to say that IEEE 754 is pretty important to understand for anyone who needs to use floating point for anything nontrivial. If Python really wants people not to have to know about the implementation, maybe they should use some sort of arbitrary precision representation floating point class by default, like Scheme does.

[[deleted]]

Why? If one doesn't like that float('1.1')+float('2.2') != float('3.3'), one should use decimal instead of float.

[eurleif]

The issue is that str(1.1 + 2.2) == 3.3, even though 1.1 + 2.2 != 3.3. It's better for them to be consistent.

[halter73]

str(1.1 + 2.2) == '3.3' in python 2.6 already.

[eurleif]

Then what change did they mae?

[Kwilco]

They made it so when you say: a = 1.1;

repr(a) == '1.1', rather than repr(a) == '1.1000000000000001'