On 11.03.2014 12:46, Nick Coghlan wrote:
...[Oscar's proposal being that picking just one decimal floating point precision as the floating point precision]...
That approach buys us a couple of key benefits:
The guidance to new users would then be don't use the decimal module, use decimal literals instead. If you need more configurable behaviour, then reach for the decimal module. However, the explicit methods on decimal context objects should probably still be updated to accept both fixed and variable precision decimals under this model.
I think you are leaving out one of the most important use cases for decimal values: data input and output.
The literals would only appear in programs. However, in most use cases, you want to read decimal data from some source, process it and then write it back again. This would most likely also require using a few decimal literals, but the main source of decimals would still be constructors that you choose when writing the tools.
Coming back to floats and the decimal constructor:
In investment banking, for example, people usually work with floats all the time. You only convert back to decimals at the very end of some calculation. The reason here being either that the calculations involve complex operations which are not available for decimals, trying to keep error intervals small, or a combination of both. In general, you try to use as much precision as you can afford (in terms of memory and speed), to keep those error intervals small.
In accounting, you often use decimals for storing data with an (usually contractually or law based) agreed upon precision and rounding logic. However, there situations where you have to go to floats as well in order to run calculations, e.g. for interest, taxes, etc.
In both situations, you want to have the decimal constructor take the float values with full precision and only then apply the necessary rounding to turn the value into a form which complies with the agreed upon rules. It's also not uncommon to add correctional bookings to address rounding issues explicitly (e.g. when calculating VAT of a large number of individual items).
In short: you try to prevent rounding from happening as much as possible and when using it, you use it in a controlled way.
Based on this, the choice to have the decimal constructor use full precision when reading floats is a good one, even though it may not feel right for the novice, the casual decimal user or as human concept :-)
For decimal literals, I'd argue that if you enter a value 1.2500d, you are expecting a decimal with 4 decimal places precision, not 64 or 128 bits :-)
The information about the intended precision is implicit in the literal. You see this done in exchange rates, stock prices, prices at your grocery store, etc.
The decimals can then be transformed into ones with higher precision during calculations and then possibly back to lower precision, but this is an explicit decision by the system doing the calculation.
Anyway, just throwing in some additional entropy into this discussion. Probably not all that helpful, since you're already converging on two possible solutions :-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Mar 11 2014)
::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/