prePEP: Money data type

John Roth newsgroups at jhrothjr.com
Sat Oct 18 13:52:37 EDT 2003


"Alex Martelli" <aleax at aleax.it> wrote in message
news:dYekb.12971$e5.447075 at news1.tin.it...
> Paul Rubin wrote:
>
> > "John Roth" <newsgroups at jhrothjr.com> writes:
> >> COBOL's default rounding policy is to truncate. It has a second
> >> rounding policy that is invoked by the keyword ROUND (surprise,
> >> eh?) However, one of the things that COBOL arithmetic has is
> >> precise control of the number of decimal places at all points in
> >> a computation[1], so if you don't like either truncation or the effects
> >> of ROUND, then you simply maintain an additional decimal place
> >> or two and do it your way.[2]
> >
> > Yeah, but what about the exact method of rounding, like the pre-PEP
> > specifies 1.125 rounds down but 1.135 rounds up (or maybe it was the
> > other way), while some other standard specifies always rounding down
> > (or up) when the extra digit is a 5.
>
> Round-to-even-cent is quite popular (Roguewave calls it "Banker's
> Rounding" in the Money class of their commercial class library).
> So is always-round-up (again in the case in which an exact
> computation would end up with a half cent, or whatever other
> least significant unit of measure), which Roguewave calls "Plain
> Rounding", and the European Union specifies.
>
> If you have a type that only performs one kind of rounding, you
> cannot use that type for legally valid money computations in
> both Europe AND America (I think: I haven't been shown American
> laws specifying rounding approaches, have just seen that "round
> to even" mentioned as being usual, habitual, or popular).

I don't think there is any consistent law covering the matter in the
US. I do know that lots of taxes come with their own tables,
calculated to the penny, and don't come with directives on how
to calculate them for yourselves.

John Roth
>
>
> Alex
>






More information about the Python-list mailing list