HP3000-L Archives

October 1998, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Walter Murray <[log in to unmask]>
Reply To:
Walter Murray <[log in to unmask]>
Date:
Wed, 28 Oct 1998 19:19:33 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
Ted Ashton ([log in to unmask]) wrote:
: I'm obviously too new to this COBOL stuff.

[snip]

: I thought
: COBOL was "the language which wouldn't lose pennies" !

Stick with ADD, SUBTRACT, MULTIPLY, and DIVIDE, and you
shouldn't have any surprises.  You have complete control
over the precision of intermediate results, as well as
whether things get rounded or truncated.

But use an arithmetic expression, as in a COMPUTE statement,
and you lose that control.  The current COBOL standard says
that it's up to each implementor to decide how to handle
arithmetic expressions.  Suppose you write:

     COMPUTE PERCENT-CHANGE = (DELTA / BASE) * 100

The standard doesn't specify how many digits of precision are
to be used for the result of the division.  You are at the mercy
of the compiler writer.  This can and does vary from one system
to another, and it takes many programmers by surprise.

This has long been recognized as a shortcoming in COBOL, and
it is being addressed in the future standard, through the concepts
of standard arithmetic and standard intermediate data items.

Bottom line:  arithmetic expressions and the COMPUTE statement
are convenient; but there are traps and pitfalls, they are not
portable, and the current standard imposes no guarantees about
the accuracy of the results.

Walter Murray
Hewlett-Packard
Support Technology Lab
COBOL II/iX Project

ATOM RSS1 RSS2