Re: Eval(R) - the R does NOT mean round...

[Hans Boldt <boldt@xxxxxxxxxx>]

William A.(Tony) Corbett wrote:
 >...
> This is on a V4R4 machine, at first I thought it was a compiler error which
> hopefully is fixed on a subsequent release.  To me, this makes the (R)
> extender less than worthless and I cannot imagine who on the Rochester
> development team thought this was a good idea, since the Eval with no
> extender (default rules) should give this same result except with more
> accurate intermediate work variables used.

Why did we consider the (R) extender useful?  Mainly over *customer
complaints* about the way the default decimal precision rules work.
  Probably you haven't run into any of the extreme cases that cause
unexpected results with the default rules, but others have.

In a nutshell, the default precision rules favor reducing the
likelihood of decimal numeric overflow at the expense of the low
order digits.  In certain situations, typically involving repeated
divisions, the precision of the intermediate results within the
expression tends towards 31 digits with 0 decimal places.

Some programmers did not appreciate losing the decimal places, and
so we provided an alternative.  When (R) is specified (or
alternatively, EXPROPTS(*RESDECPOS) on the H-Spec), *IF* there is a
target variable, the compiler will not reduce the number of decimal
positions within the expression below the number of decimal
positions of the target variable.  And so, in EVAL statements (and a
few other places), you get all the decimal digits you want, but with
a corresponding slight increase in the risk of numeric overflow.

Cheers!  Hans