In article <[EMAIL PROTECTED]>, "Simon Brunning" <[EMAIL PROTECTED]> writes: |> > |> > Financial calculations need decimal FIXED-point, with a precisely |> > specified precision. It is claimed that decimal FLOATING-point |> > helps with providing that, but that claim is extremely dubious. |> > I can explain the problem in as much detail as you want, but would |> > very much rather not. |> |> Sorry, Nick, you might have to. ;-) |> |> I'm not educated in these matters, so I'd genuinely like to know why |> you say that. Not educated, but I do have some experience; I've used |> both fixed and floating point Decimal types extensively, and I've |> found floating types superior. More fiddly, certainly, 'cos you have |> to explicitly round back down to the precision that you want when you |> want. But explicit is better than implicit - the number of subtle |> rounding bugs that I've had to fix 'cos someone didn't realise where |> rounding was occurring is, uh, well, it happens from time to time. ;-) |> |> What am I missing?
I will try to give a simple explanation, but I need to gloss over a hell of a lot. The precision is the number of digits after the decimal point. Financial calculations are defined in terms of decimal fixed-point, with precisely specified precisions and rounding rules (though both may vary with context, even in one expression). Now, let's ignore the arcana (especially as I know only a little of them) and note only the following: The traditional way of implementing fixed-point is as scaled integers, and this is easy and reliable. It is tricky if the USER is expected to do it, but it is trivial to excapsulate. Hell, even PLAN (the ICL 1900 assembler) did it! If a number is calculated in floating-point, decimal or otherwise, and needs any rounding, then it will NOT follow the right rules and no reasonable amount of post-operation munging will enable it to do so. Fixing up double rounding problems is inherently foul, so it is ESSENTIAL that no operation is approximate. In true fixed-point, the result of multiplication has a precision that is the sum of the input precisions, and addition, subtraction and remainder the maximum of the two. Division is required to specify a target precision and rounding rule. Overflow is raised when the total number of digits exceeds the space available. A typical financial multiplication is a monetary amount multiplied by a rate (say VAT, interest or a conversion rate). That typically has up to 5 digits, but there is no reason that it can't be more, and it is possible that some calculations multiply several rates together. When emulated in floating-point, the exception raised when the number of digits exceeds the space available is Inexact (there is a slightly different one for decimal, but the differences don't matter here). So, to get correct fixed-point flag handling, Inexact must be mapped to Overflow. Except for division, where there is no way to use the floating-point primitive as a basis for the fixed-point one, so it has to be done by hand, tediously and slowly. But, in scientific (and current Python) usage, Inexact is always ignored and Overflow is almost always an error. If we do that mapping, it will break ALL scientific code. But, if we DON'T do that mapping, we will abandon any attempt at getting reliable fixed-point overflow detection. So you can't mix the two in the same program - which was one of the main objectives of using decimal floating-point! The counter-argument is that everyone will use 128-bit arithmetic for all purposes. Well, that is hooey, because it will cause MAJOR problems for both the embedded people (logic, power and performance) and HPC people (performance, mainly bandwidth). Python could, probably. However, that isn't what the Decimal module does anyway. People will specify more digits than they possibly need, not realising that they need to specify many MORE if they are going to support multiplication. Coming back to the start, is fixing that little lot up REALLY easier than encapsulating scaled integers to give a proper fixed-point type? I think that you will find that it is much harder! Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list
