|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.