Re: [Re: RPGILE V4.3 Gotcha]

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

boldt@ca.ibm.com wrote:

> <SNIP>

> Jim:  Have you studied Chapter 21 of the ILE RPG Reference
> manual?
>
> You want decimal arithmetic to be done precisely regardless
> of the size of the value?  Here's how to do it:  Do your
> arithmetic in a REXX program with the following statement:
>
>        NUMERIC DIGITS 1000
>
> (If a thousand digits isn't good enough, just change it to a
> bigger number.)  But guess what the performance of your
> program will be like?
>
> Although the performance of interpreted languages is becoming
> a less significant factor in choice of programming language,
> most shops tend to prefer the performance advantages of
> compiled languages.  But these performance advantages come
> with constraints, such as RPG's 30 digit maximum on the
> precision of decimal values.  (Or IEEE's design of floating
> point values, which limits precision to no more than 17
> digits, at best.)
>
> I take issue with your assertion that it is not safe to do
> ANY type of math on any number that contains a fraction.
> (I'm sure the vast majority of programmers who do code their
> arithmetic in expressions would also disagree!)  The rules
> for decimal arithmetic in expressions are documented in
> Chapter 21 of the ILE RPG Reference.  If you want to be able
> to code decimal expresssions safely, you need to understand
> those rules.  If you still have questions after studying
> Chapter 21, I'd be quite happy to answer them.
>
> You could always stick to the traditional ADD, SUB, MULT, etc
> opcodes.  But since the default behavior of those is to
> truncate results instead of failing on numeric overflow,
> those opcodes are the real unsafe ones!
>
> 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
> +---

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