Re: [Re: RPGILE V4.3 Gotcha]

Jim,

I must respectfully protest your response.  RTFM is a mantra on this list and on
the MIDRANGE-L.  If you refuse to educate yourself on the intricacies of numeric
expressions using EVAL, as Hans suggested, then you need to revert back to your
ADD, DIV, SUB, & MULT opcodes.  The opening paragraphs of chapter 21 make it
very clear:

  Unlike the fixed-form operation codes where you must
  always specify the result of each individual operation,
  RPG must determine the format and precision of the
  result of each operation within an expression.

  It is important to be aware of the precision rules
  for decimal operations since even a relatively simple
  expression may have a result that may not be what you
  expect. For example, if the two operands of a
  multiplication are large enough, the result of the
  multiplication will have zero decimal places.  If you are
  multiplying two 20 digit numbers, ideally you would need
  a 40 digit result to hold all possible results of the
  multiplication. However, since RPG supports numeric
  values only up to 30 digits, the result is adjusted to 30
  digits. In this case, as many as 10 decimal digits
  are dropped from the result.

Quite honestly, I don't understand how anyone can expect the compiler to guess
what precision is needed in a particular situation.  What might the right
precision scenario for you in a given situation may be the wrong one for someone
else.  Are the precision rules for EVAL expressions more complex?  You betcha.
But that's a result of having the ability to code complex expressions.
- Dan Bale

___________________________ Original Message __________________________

If I define a variable as 15.5, then try to multiply 10,000,000,000 x 1,000,000
it is going to overflow, either by truncating as in MULT or however RPG does
it.  Either way, it's not going to work.

If I have a dollar amount stored in 15,2, and I do some simple math on it, for
instance, I want to put in my markup of 150% and then calculate sales tax, and
store it in Total, which is also 15,2 I might do something like
EVAL Total = Amount * Markup * Tax
it is possible using EVAL that I will get an inaccurate result, even if the
value falls within the 15,2.

I make my numeric variables extra large so I don't have to worry about overflow!
And I am not the one to declare all the variables in the first place, but the 2
or 3 programmers than preceded me.

Basically, it amounts to this: I don't want to worry about overflow on SIMPLE
calculations, where I know there won't be any overflow.  Where I know that the
value is going to fall within my range.  Overflow I've lived with since I
started programing, and learned to deal with it.  To look at the size of my
values, the size of the variables holding them, and watching my math.

But now, it seems, if we use the EVAL statement to do mulitplication all the
rules are changed?  That I'm going to overflow with larger size variables than
smaller size?  That I'm going to loose precision because my variables are too
big?

It is known that if you multiply two 15 digit numbers by each other, if either
of the numbers were rather large that the result is not going to fit in return
variable.  But, I know this.  And I'm going to scale my variable sized
accordingly.  I'm going to make my result variable large enough to hold the
value of my math, or I'm going to rightly expect an overflow, or truncation of
precision on my decimal part.

I do not expect the compiler to start changing the size of my variables to what
it thinks is best and mess up my answer.  If I thought the variable would
overflow 15 digits, I'd make it larger, but I'm going to keep it within reason
and leave sufficient space for my variables.

No, I have not read the area on math, because the only math I am doing on this
machine is 2 significant decimal digits in length, at the most 3.  We are
dealing with dollars and cents here.  The point is, I shouldn't HAVE to read the
manual.

Regards,

Jim Langston





+---
| 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
+---