Release of Python 2.4, release candidate 1

What's New in Python 2.4 details the changes and additions in this release. Download the release here.

Most of the additions were discussed here in the past. Notable among them are generator expressions and function and method decorators.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Python just went down in my estimation

However, while most programming languages provide a floating-point type, most people (even programmers) are unaware that computing with floating-point numbers entails certain unavoidable inaccuracies. The new decimal type provides a way to avoid these inaccuracies.

There are uses for a decimal floating-point library- monetary calculations and other places where rounding things off the same place you would if you were doing it by hand. But selling it as a solution to round-off problems just convinces me that the maintainers of Python don't know diddly about numerical analysis, or the problem (and it's solutions).

If you wish to maintain that the solution has, in fact, been found, please post the decimal (or any other rational base of your choosing) representation of the solution to x2 = 2.

They haven't avoided round-off, nor the problems it engenders. The round off problem doesn't come from the fact that floats are binary based. They come from the fact that fp numbers, and all numbers held in a computer, are finite in their representations. They've just changed when the roundoff happens. The problem remains. Which is why the designers of the IEEE 754 standard (who did know something about numerical analysis) choose a binary representation. You're going to have the problem no matter what base you use, you might as well use a representation that gives you the most information per bit of storage, and the fastest implementations in modern circuitry.

Not quite that bad

The first paragraph, which you have quoted, is indeed not correct. This new type doesn't avoid inaccuracies caused by using a finite number of digits.

However, that is not the problem it's trying to solve either. Check out the external links, such as http://www2.hursley.ibm.com/decimal/decifaq.html

As far as I can see, it is just like the GNU arbitrary precision library, but with base 10. As you can see, the main focus is on operations that involve numbers such as "0.1", which cannot be represented exactly in base 2, and rounding. They are trying to round to the nearest cent to comply with financial procedures, etc., which is less problematic in base 10,

It is probable that their computations require more accuracy than what binary double precision provides, so they may have been already using software-powered arbitrary precision types. While they're at it, why not change the base to 10 as well if it is going to help comply with rounding rules.

Yes, it is that bad

The very first sentence I wrote, immediately after the quote, was:

There are uses for a decimal floating-point library- monetary calculations and other places where rounding things off the same place you would if you were doing it by hand.

If they had stated this as their rationalization, my response would have been "good idea". I am quite aware that there are reasons to not use binary FP. But that is not the excuse they gave. The problems with using this excuse is manifold- an incomplete list would include:

  • It encourages programmers to think the roundoff problem has been solved, when it hasn't ("well, why hasn't your programming language solved this problem, when Python has implemented the obvious solution?").
  • It encourages the use the decimal FP instead of binary FP even in places where binary FP is preferred, slowing down programs unnecessarily.
  • It encourages programmers to not check for nor learn about round off error, it's causes, or it's solutions, as that problem has now been solved.
  • It shows both that the Python designers have no knowledge of numerical analysis but that they think they do. This time they didn't screw up- but not because they know what they're doing, and not because they're listening to people who know what they're doing, but because they got lucky. What else did they meddle with where they didn't get lucky? Note that Python is not the first programming language with this problem.

Nor does throwing more bits at the problem generally help. If you're losing precision, you're losing precision. Most often, you're losing precision in an exponential rate- which means if 64 bits allows you to do 6 steps, 4096 bits allows you to do 12. 64-bit double precision floats give you 15 decimal digits of precision- enough precision to measure the distance from here to the moon in microns (1/1000000th of a meter), or the gross economic production of the entire planet to the penny. If anything, most financial applications don't need that amount of precision (if you're calculating interest on the national debt, maybe). The problem isn't the amount of precision, but when rounding occurs. The financial application wants the rounding to occur exactly the same as the rounding the gnome of zurich does when doing it in pencil on paper- even if the binary result is more accurate.

Nor was the example I gave (calculate sqrt(2) with no precision loss) snarky either- this shows up in real-world problems as well. Gram-Schmidt normalization is an example- in the standard way it's done, your scaling each vector to be a unit vector at the end of a step, a vector which is used in later steps of the algorithm. Unfortunately, you often times get vectors like [1; 0; 1]- which can be precisely represented in both binary and decimal FP just fine. But when you try to make it a unit vector, you end up with [1/sqrt(2); 0; 1/sqrt(2)] which can not be represented exactly in any finite number of digits in any base you want. This introduces an error in the calculations, which propogates through the entire algorithm, and very quickly your "answer" is nothing but round off error (the solution, by the way, is to not make the vector into a unit vector, and just leave it in it's non-unit form. This turns the algorithm into a stable algorithm). This problem does show up in the real world.

Documentation mistake

If they had stated this as their rationalization, my response
would have been "good idea". I am quite aware that there are reasons to
not use binary FP. But that is not the excuse they gave.

I think it's just a mistake on part of the writer of
the What's New document,
the original
design document
doesn't make the claim.

Not the case...

There was an extremely voluminous discussion that went into the design of the decimal module; more than I could ever have imagined being appropriate for something that seems, well, not that complicated. But obviously it was complicated, and many people participated in the design, trying to come to a compromise on the conflicting goals of accuracy and ease of use.

You read way too much into a single point of documentation; asserting that Python designers have no knowledge of numerical analysis is both false and easily disproven by reading the referenced PEP on the design of the module. But obviously Andrew couldn't include that lengthly discussion in the What's New document; maybe he chose the wrong way to summarize, but it's not helpful for you to go off on the entire group behind the design of Python for such a pedantic point.

> It shows both that the Pyth

It shows both that the Python designers have no knowledge of numerical analysis but
> that they think they do.

This is a grossly unjust statement. My observation - as someone outside of the Python development process, but who looks in on it from time to time - is that there are Python developers who know more about numerical analysis than can possibly be good for one persons brain. If you want a good example, read Tim Peter's often insanely detailed posts over many years on floating point numbers.

What else did they meddle with where they didn't get lucky?

Please, would it really hurt you to afford the Python developers a little more respect? Yes, I bet they've made some bad decisions from time to time (though nothing I've seen suggests that this particular example is a bad decision), but haven't we all slipped up from time to time? I think there's plenty of evidence that, all in all, they've done a pretty good job over the years. Certainly they don't deserve your accusations of incompetence and computing terrorism.

Idiots should go ahead and eschew Python

If they had stated this as their rationalization, my response would
>have been "good idea".

So you managed to find something in one line, taken out of context, in a beta version of some release notes, that--if read in the most ungenerous fashion possible--might be mildly untrue.

All the while, you never read the relevant PEPs, the developers' mailing list, public newsgroups, the implementation code, or anything at all relevant to what the decimal type actually does.

Lovely... please go ahead and stay away from Python...

Comment from document author

Note that I'm the only author of the "What's New" document, and I just describe what's been added; I didn't have any design input in the Decimal type and don't do numeric work.

The motivation for talking about "inaccuracies" here was that many users discover that 46.85, say, is printed as 46.850000000000001, and post questions to c.l.python wondering if there's a Python bug or less commonly a platform bug. This seemed like a good simple hook for explaining why a decimal type is useful.

Would you be happier with the given paragraph if it said something like "...inaccuracies when representing common decimal fractions."? If not, how would you suggest I rewrite the text?

Well

Whatever you end up writing, I think you should definetely have it reviewed by the people that participated in the design decision. It's surprising that they didn't personally get involved in the user documentation.

"...computing with floating-point numbers entails certain unavoidable inaccuracies. The new decimal type provides a way to avoid these inaccuracies."

The first part is still true for the new decimal type as well, so the 2nd sentence is wrong because the new type doesn't avoid "all" inaccuracies.

It makes a lot of decimal numbers exactly representable, though, and I am under the impression that it matches the financial practices better when it comes to rounding figures. An individual number could be more precise, but the calculations are not guaranteed to be more stable than regular FP, i.e. you can still get hosed if you are not careful, some assembly required, batteries not included, etc.

Well

The user documentation for the module is part of the library reference, and perhaps PEP 327. The "What's New" document is an overview, not a detailed reference or specification.

Anyway, I'll edit the sentence to make it clear that the reference is to the inaccuracy of decimal fractions.

Lamda just went down in my estimation

Brian says: "Python just went down in my estimation" and one proof is "the designers of the IEEE 754 standard choose a binary representation."

So I say: "Lambda just went down in my estimation" and one proof is "the same designers created IEEE 854, which can accept both binary and decimal representation".

My point here is just to show how you take an incorrect snippet from one person (who accepts your comment), and accuse the encompassing project for it. You're overreacting. Thanks for pointing the mistake out, but making such a fuss about it is a waste of energy. Too much stress at work? Hit a pillow.

Language design

1. It seems to me that even if the What's New document is faulty, this shouldn't be enough to loose faith in an entire language.

2. Languages are complicated, so is language design. I guess that on LtU we should keep this in mind. Suppose the decimal type is badly designed, does this really entail the whole language and/or the whole process if faulty? I am not sure. What do others think?

3. Can we keep LtU free of flames? Criticism is fine, of course...