I have faced a mysterious problem while using the COMPUTE function in AS/400.
The scenario is as follows:
01 WSAA-AMOUNT-A PIC S9(15)V9(02) COMP-3.
01 WSAA-AMOUNT-B-01 PIC S9(16)V9(02) VALUE 0.
01 WSAA-AMOUNT-B-02 PIC S9(13)V9(05) VALUE 0.
01 WSAA-AMOUNT-C PIC S9(16)V9(02) VALUE 0.
01 WSAA-RESULT PIC S9(15)V9(02) VALUE 0.
MOVE 2500.87 TO WSAA-AMOUNT-A.
MOVE 12285 TO WSAA-AMOUNT-B-01.
MOVE 12285 TO WSAA-AMOUNT-B-02.
MOVE 4387.5 TO WSAA-AMOUNT-C.
COMPUTE WSAA-RESULT ROUNDED = (WSAA-AMOUNT-A / ( WSAA-AMOUNT-B-01 + WSAA-AMOUNT-C) * 100 ).
DISPLAY WSAA-RESULT.
COMPUTE WSAA-RESULT ROUNDED = (WSAA-AMOUNT-A / ( WSAA-AMOUNT-B-02 + WSAA-AMOUNT-C) * 100 ).
DISPLAY WSAA-RESULT.
The results surprised me that the result from the first formula = 14.90
while the second one became = 15
It sounds the later one is more logical as 2500.87 / (12285+4387.5) * 100 = 14.99997001.
I expect the result from first result should be 15 too after rounding.
Does anyone know what is the root cause for those inconsistent results?
The results achieved were 14.90 and 15.00.
The COMPUTE is poorly-formed. When multiplying by 100, do it as early as possible, because if you do it last, two decimal-places disappear (when dividing by 100, do it last, so you don't lose significant digits early on).
It doesn't only apply to 100, so think about it. Multiply first, divide last, whatever values are involved. It is entirely unnecessary to use a field with five decimal places to get the "correct" answer, unless you require five decimal places in the final answer.
The computer is not a calculator or spreadsheet. It uses intermediate results depending on what you ask for rather than the others which give you numerous decimal places for anything. You ask for decimal precision using the number of decimal places in the fields you use.
One key to understanding what is going on is the Fine Manual. Another is experimentation. This can often be a general answer.
COMPUTE WSAA-RESULT ROUNDED =
(WSAA-AMOUNT-A / ( WSAA-AMOUNT-B-01 + WSAA-AMOUNT-C) * 100 )
DISPLAY WSAA-RESULT. gets the answer 14.90 (fourteen point nine-zero).
COMPUTE WSAA-RESULT =
(WSAA-AMOUNT-A / ( WSAA-AMOUNT-B-01 + WSAA-AMOUNT-C) * 100 )
DISPLAY WSAA-RESULT. gets the answer 14.00 (fourteen point zero-zero), by removing the ROUNDED.
COMPUTE WSAA-RESULT ROUNDED =
(WSAA-AMOUNT-A / ( WSAA-AMOUNT-B-02 + WSAA-AMOUNT-C) * 100 )
DISPLAY WSAA-RESULT gets 15.00 (fifteen point zero-zero) the "correct" "expected" answer, by using five decimal places.
Remember, you multiplied, last, by 100. So before that the values were 0.149 (three decimal places), 0.14 (two decimal places) and 14.99999n (six decimal places, and I'm not going to do the calculation again, so I've left the sixth as "n").
Why are there three, two and six decimal places? The six is because of the B-02 (with five places, plus one for ROUNDED, which increase the required decimal places by one, so that the ROUNDED can be calculated), the two because of the B-01 (with two decimal places) the three is because of the B-01 and ROUNDED.
Here is a re-worked COMPUTE, in the three versions:
COMPUTE WSAA-RESULT ROUNDED = ( ( WSAA-AMOUNT-A * 100 )
/ ( WSAA-AMOUNT-B-01
+ WSAA-AMOUNT-C ) )
COMPUTE WSAA-RESULT = ( ( WSAA-AMOUNT-A * 100 )
/ ( WSAA-AMOUNT-B-01
+ WSAA-AMOUNT-C) )
COMPUTE WSAA-RESULT ROUNDED = ( ( WSAA-AMOUNT-A * 100 )
/ ( WSAA-AMOUNT-B-02
+ WSAA-AMOUNT-C) )
The results are 15.00, 14.99 and 15.00.
This is with Enterprise Cobol. It seems OpenCobol uses different intermediate results, which are probably documented.
Here is the Enterprise Cobol Programming Guide on intermediate results:
"To understand this information about intermediate results, you need to understand the following terminology.
...
d The number of decimal places carried for an intermediate result. (If you use the ROUNDED phrase, one more decimal place might be carried for accuracy if necessary.)
dmax In a particular statement, the largest of the following items:
v The number of decimal places needed for the final result field or fields
v The maximum number of decimal places defined for any operand,
except divisors or exponents
v The outer-dmax for any function operand"
and
"Operation ... Decimal places
+ or - ... d1 or d2, whichever is greater
* ... d1 + d2
/ ... (d2 - d1) or dmax, whichever is greater"
With the "erroneous" example, the addition gets two decimal places (both d1 and d2 are two for the addition), the division gets three decimal places (dmax is three) and the multiplication gets three (two + zero + one for the ROUNDED). The final answer, after rounding is attempted (it will never operate, as the two low-order decimals are always zero due to the multiply by 100), is truncated to two decimal places.
For the ROUNDED B-01, dmax is three (result field of two places, plus one for rounding). For the plain B-01, dmax is two. For the ROUNDED B-02 dmax is six.
Note, it is not only the example shown which is wrong. ROUNDED never operates in the first example in the question, and one significant decimal is always dropped, so you only obtain the correct answer at the times when the answer before rounding is in tenths. These correct answers are then masked by nine further answers which become the same due to truncation.
If you always write effective COMPUTEs, you won't run into problems. ROUNDED only operates on the final result. If you need any intermediate fields ROUNDED, calculate that separately and use the result in a new calculation.
COMPUTE works. COMPUTE does not operate like a calculator/spreadsheet. Nor does any other Cobol verb (they are verbs not functions). Think about how to write the COMPUTE so as not to loose significance. Read the manual. Experiment. Repeat until correct and understood.
