prePEP: Money data type

[John Roth]

"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
news:7xbrse3bup.fsf at ruckus.brouhaha.com...
> Alex Martelli <aleax at aleax.it> writes:
> > > 1. I've seen lots of strange rounding policies in various nooks
> > > and crannies. Is there any way of specifying a rounding policy
> > > that would be used and inherited by the result money object?
> >
> > Amen, Hallelujah.  I've followed up to Batista's similar post to
> > python-dev by pointing out chapter and verse of EU regulations that
> > _mandate_ "rounding to nearest and always round exactly-halfway
> > UPWARDS", for example.
>
> Are you serious about this?  I thought financial computations with
> decimal arithmetic had been done in Cobol since the 1950's.  They
> haven't gotten this stuff figured out by now?  Can you crunch some
> calculation through a Cobol program and get an answer that's correct
> in the US and wrong in the EU?

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]

The difficulty here is that the control is maintained by declaring
what the *output* of an operation looks like, and that's
pretty much impossible for a language that doesn't have
declarations.

John Roth
(who hopes to never see another COBOL program in his life -
unless you're paying him big bucks, of course... [grin])

[1] Unless, of course, you're using the COMPUTE verb.

[2] Unless that would run you over 18 digits. Why 18, I
have no idea, and I'm afraid that most of the people on the
original COBOL committee are no longer with us.