prePEP: Decimal data type

[Aahz]

In article <Xwnqb.422473$R32.14001017 at news2.tin.it>,
Alex Martelli  <aleax at aleax.it> wrote:
>Tim Peters wrote:
>>
>> You do need to explicitly round (if desired) after * and /.  Because of
>> the high value attached to 100% conformance to imposed standards in
>> accounting apps, I think it's a good thing that you're forced to round
>> explicitly when the result of a calculation can't be represented exactly
>> in the mandated format -- those are exactly the places where your app will
>> fail to meet the requirements, so it's good to be aware of them.
>
>European Union directives (adopted as laws by member states)
>mandate the rounding procedure to be used in computations involving
>Euros (round to closest Eurocent, always round up on half-Eurocent
>results); they very explicitly mention that this may give a 1-Eurocent
>discrepancy compared to "exact" arithmetic, and give examples; they
>establish that such a 1-cent discrepancy that comes from following
>exactly the prescribed rules is NOT legal cause for any lawsuit
>whatsoever; they earnestly recommend that all computing equipment and
>programs follow these same rules to avoid the huge headaches that would
>result in trying to reconcile accounts otherwise.

Yeah, but *what* do you round?  If you purchase five items in a store,
does tax get applied to each item individually or to the total?  There
are lots of similar cases, so rounding must still be at least partially
explicit.

>Whether Decimal itself allows an optional rounding-policy (including
>of course "no rounding" as a possibility) is one issue (I guess that
>might violate some ANSI or IEEE standard...?) but I most surely do want
>to be able to use such policies in whatever arithmetic type underlies
>Money -- so I hope Decimal is at least designed so that _subclasses_
>can easily provide such customized rounding (e.g., feature-testing
>for a __round__ specialmethod, not defined in the baseclass Decimal
>if need be, but offering the needed hook for subclasses to add the
>functionality).

Once again, I suggest that you read Cowlishaw.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan