monetary applications [was: Python GUI app to impress the bos s?]

[Dave Cole]

>>>>> "Dennis" == Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

Dennis> Paul Boddie fed this fish to the penguins on Thursday 19
Dennis> September 2002 01:14 am:


>> It could well be that not many people do financial database
>> programming in Python, bizarre and unlikely as that may
>> seem. Taking a look at pyPgSQL, as the only database module I have
>> installed that actually readily documents such things (and that
>> should tell you something), it would seem that monetary amounts are
>> converted to floating point numbers - surely the first thing one
>> would want to avoid in manipulating financial data. Perhaps people
>> use integers, or perhaps other modules provide better decimal
>> support.

Dennis>         If I recall from the c.l.ada group, GNAT's "fixed
Dennis> point" data type is implemented as scaled integers, so even
Dennis> that might not pass the spec for a monetary type. My VB
Dennis> references are on loan (or currently stuck in the Windows
Dennis> environment and unreadable on Linux) so I can't recall what
Dennis> VB6 had for fixed/monetary.

Dennis>         The only language I've ever encountered that had a
Dennis> truely monetary safe fixed point data type is COBOL -- which
Dennis> has always used packed BCD formats (though where the sign
Dennis> "bit" is stored may vary). COBOL was created from the
Dennis> beginning for "business" applications (heck: COmmon Business
Dennis> Oriented Language) and was spec'd by a government team. My
Dennis> college mainframe required /four/ of the sixteen registers to
Dennis> hold /one/ BCD number (32 BCD digits, 2 digits/byte, 16bytes @
Dennis> 4/register).
 
I while ago I worked for a stock broker and developed some Python code
for doing financial post trade calculations.  I sweated quite a bit
about loss of accuracy in stamp duty, GST, and commission calculations
until it was pointed out that errors of a few cents here are there are
considered normal.  For larger amounts of money (100's of 1,000's of
dollars) an error of around a dollar would be more or less
transparently handled within the various back end systems used between
the trading organisations (institutional investors and stock broker).

It might be worth talking to the actual users of the software to see
what margin of error is considered normal before getting too upset
about achieving 100% accurate results.  You may be able to get a
provably correct answer in your code, but you have no control over the
software being used by other people (if there are other people).

I found my largest problem was trying to repeat the calculations being
performed by a third party system and reproduce the truncation and
rounding that was evident in their final numbers.

- Dave

-- 
http://www.object-craft.com.au