Decimal arithmetic, was Re: Python GUI app to impress the boss?

[John Roth]

"Tim Peters" <tim.one at comcast.net> wrote in message
news:mailman.1033584066.24607.python-list at python.org...
> [Tim]
> >> Then please help Doug do that, including *defining* the
> >> rounding disciplines you think are needed; I was never able
> >> to bully <wink> those out of its users,
>
> [Chris Gonnerman]
> > I keep hearing this... what is the problem, exactly?
>
> I think the replies (including two of your own <wink>) spoke more
eloquently
> to this point than I could.  The rules various commercial apps want
are
> utterly arbitrary by any rational criterion ("always round up", "round
up
> over 0.4", "round up over 0.7", "it depends on the *next* digit too",
etc),
> but that doesn't mean an arbitrary piece of code satisfies the
requirements.
> If I were still doing this, I expect I'd invent a way for users to
plug in
> their own "final rounding" function, and explicitly disown
responsibility
> for guessing what they want.

Exactly. The question is how. I'm leaning to making it a property of the
fixed point number object, but I don't see how that works as far as
either
literals or combining two fixed point objects with different rounding
policies
would go.

The best prior art I can figure is from COBOL, where most of this
stuff happens today. There, the rounding policy is set by the _result_
picture, which is a concept that simply isn't availible in Python (or
most
other "modern" languages, for that matter.)

And even there, oddball rounding policies require fixup code because
the language doesn't include anything other than round up if the
fraction
is >= .5.

John Roth
>
>