Re: [Re: RPGILE V4.3 Gotcha]

Frank wrote:
>The point I am making is that the program work fine as RPGIV ILE code under V4
>R2 .  When we went to V4 R3 it produced the gotcha.

This is what I don't understand about your note.  The V4R3 ILE RPG
compiler is exactly the same compiler you used under V4R2.  No
difference.  (Except perhaps for additional PTFs, but these wouldn't
change the behaviour of the arithmetic precision rules.)  Except for
some additional options, the precision rules haven't changed since
V3R1.

>How many other instances
>are out there waiting to pop up?  I needed to put in the new BIF %DEC so that
>the program procuded the correct result at 3 decimals.  The bit about
>precision is a mystery to me.  What is the difference between decimals and
>precision.
>
>Anyway all the formulae should produce the same result, they do not.

This question pops up occasionally, especially for those new to ILE
RPG IV.  (Is anyone out there writing up a FAQ list?)

Have you read Chapter 21 of the ILE RPG Reference?  Expecially the
section called "Precision Rules for Numeric Operations"?  Basically,
whenever you have complicated arithmetic expressions, the results of
individual operations are stored in compiler generated temporary
variables.  The sizes of these temps is determined by the sizes of the
operands.  For example, if you multiply two decimal values, say a (10,2)
value times a (5,3) value, the result is a decimal value with precision
(15,5).  But in cases where the natural precision of the result is
greater than 30 digits, we truncate down to 30 digit precision.  In
order to minimize the likelihood of numeric overflow, we first reduce
digits to the right of the decimal point.  Table 35 (in Chapter 21)
lists the rules for all operations.

Let's look at one of your statements in detail:

       EVAL(H)   DAABE(07) = RCDNC1 / 100.00 * DTITRD * DTIQNS
                             (11,3)   (5,2)    (15,4)   (11,3)

The evaluation of this expression proceeds as follows:

1) RCDNC1 / 100.0    ->   (11,3) / (5,2)     =>  (30,20)
2) (temp) * DTITRD   ->   (30,20) * (15,4)   =>  (45,24) => (30,9)
3) (temp) * DTIQNS   ->   (30,9) * (11,3)    =>  (41,12) => (30,1)

As a result of applying the precision rules, you end up with a
decimal precision of (30,1), which is what you see in the answer.
(I'll leave it to you to work out how the other answers are computed.)

As someone else already mentioned, perhaps what you should do is
code EXPROPTS(*RESDECPOS) on the H-Spec.  This ensures for all
decimal expressions that the number of decimal positions in temporary
variables never drops below the number of decimal positions in the
corresponding result variable.  (You could also code opcode extender
R on the EVAL.)  This is probably better than using %DEC to control
intermediate result precision.

In the example above, using *RESDECPOS, the precision of the result
in step 3 would be (30,4).  The result variable has precision (15,3).
The compiler adds an extra digit of precision because you also
specified half-adjust on the EVAL.

Note that using *RESDECPOS is not a general panacea, since it cannot
work in cases where there is no result, such as in logical expressions.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---