Re: financial computations

[Robert Dewar <robert_dewar@my-deja.com>]

In article <3918A193.9800E973@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> Robert Dewar wrote:
> > in several contexts, including bond interest
> > calculations, the calculation of interest must be done
precisely
> > in decimal arithmetic, with specified truncation or rounding
> > semantics. You can only approximate this in floating-point.
>
> That's not quite the same thing as illegal, is it?

Actually, yes it is. The relevant codes require adherence
to the prescribed approaches, and specify penalties for
non-compliance.

> With 64-bit mantissae available in several programming
> languages,
> including Ada according to GNAT, if I know the rules, I can
> approximate this stuff for a million lifetimes before I lose
> a cent.

That's quite incorrect, because you need to control whether
each operation truncates or rounds, and that is not possible
with floating-point, since the floating-point engine itself
is typically set to round all the time, and as I am sure you
know rounding followed by truncatation is not equivalent to
truncation. Also everything has to be done as if it were in
scaled decimal. You cannot use floating-point binary to
accurately represent scaled decimal (you might want to look
at what Kahan has to say about decimal vs binary arithmetic,
there are a LOT of surprises for the uninitiated there).

> Realistically, I expect that when I do lose that penny
> there will be some character at hand who will point out the
> error and gloat without mercy.

The problems are very much worse than simply losing a penny!

> > COBOL has no defined semantics for exponentiation, so I do
not
> > know what you are talking about here at all.
> >

> Let me practice some mentalism, go a little deeper into my
> catatonic  trance, and look deep into our past ....   I see a
> COBOL compiler   ... I see ADD ... I see SUBTRACT ... I see
> MULTIPLY ... I see DIVIDE ... but I don't see EXPONENTIATE.
> Could be you are right about this one, Robert. But wait,
> what's this?  I see COMPUTE ...  It has expressions ...  It
> has arithmetic operators ... It has +, -, /, *,  and, aha,  **
> for exponentiation ... and ** is very, very  slow. When I wake
> up it will be almost finished ....

Well I have to admit that I set a bit of a trap there that you
fell right into. I assure you I would not have made the
statement about ** being undefined without knowing what I
was talking about (I know COBOL rather well, see below) :-)

COMPUTE has undefined arithmetic semantics. It is for example
quite fine to use floating-point for all calculations in
COMPUTE. There was even talk of REQUIRING the use of IEEE
long form floating-point for COMPUTE in the 9x standard, but
that was too controversial. There is definitely no need for
** to be very very slow, given that it can perfectly well
be done in floating-point.

However, many (most?) COBOL shops deprecate, or even forbid
the use of COMPUTE completely precisely because it has undefined
semantics (just like Fortran, or C, or C++). That's an important
difference with the verbs ADD SUBTRACT MULTIPLY DIVIDE which
have precise implementation-independent semantics. So I am
afraid your catatonic trance is not serving you well. COBOL is
a fairly complex language. Few know it really well from a
language definition point of view, and the subset of people
who really know COBOL *and* Ada 95 is even smaller.

By the way, in case people don't know I was one of the principle
authors of Realia COBOL, one of the main PC based COBOL
compilers, now marketed by Computer Associates, so I am indeed
a member of that smaller subset :-)

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.