Lambda the Ultimate

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.

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.

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.

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 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.

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...

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?

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.

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.

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.