View previous topic :: :: View next topic

Author 
Message 
shalem
New User
Joined: 11 Apr 2005 Posts: 8




Hi, can you please help me ROUNDED issue in COMPUTE statement
AVERAGERATE PIC S9(3)V999 COMP3.
COMPUTE AVERAGERATE (S1, S2, S3) ROUNDED =
(((TOPVALUE (S1, S2, S3) /
BOTTOMVALUE (S1, S2, S3))  1.0) * 100).
TOP VALUE/BOTTOM VALUE = 12024546.51/11674330.16= 1.029998
1.0299981.0=0.029998
0.029998*100= 2.9998
When I gave rounded option why I am getting 2.99 instead of 3.00 

Back to top 




Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA




COBOL does not carry the precision of intermediate results that you might expect. Study "Appendix A. Intermediate results and arithmetic precision" in the Programming Guide. Also, how are S1, S2, and S3 defined? 

Back to top 


Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA




Also, what is TOP VALUE and BOTTOM VALUE? Do you mean the Intrinsic functions MAX and MIN? 

Back to top 


Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8391 Location: Dubuque, Iowa, USA




First of all, your post is inconsistent  if AVERAGERATE is defined PIC S9(3)V999 then there is NO WAY it will ever have a value of 2.99 or 3.00; 2.999 or 2.990 or 3.000 but not with just 2 decimal digits.
Second, since you haven't posted accurate information (if TOPVALUE is a function you wrote, why not post it  and if it is NOT a function, why did you not post the EXACT code you are using) this is no way we can tell you why the rounding is not correct. 

Back to top 


shalem
New User
Joined: 11 Apr 2005 Posts: 8




Thanks for quick reply. Both Top and Bottom values are defined IN ARRAY
TOPVALUE PIC S9(14)V99 COMP3.
BOTTOMVALUE PIC S9(14)V99 COMP3.
If COBOL does not carry the precision of intermediate results then what is alternate for me. 

Back to top 


Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8391 Location: Dubuque, Iowa, USA




Have you considered making TOPVALUE and BOTTOMVALUE V999 instead of V99 and see if that makes a difference? As Terry indicated, the COBOL rules for intermediate results are NOT easy to understand without a LOT of experience. If some of your intermediate results only have 2 decimal places, you're going to get 2 decimal places in the result in most cases.
Quote: 
If COBOL does not carry the precision of intermediate results then what is alternate for me. 
Possible solution 1: carry more decimal digits after the decimal point so the intermediate results have more digits.
Possible solution 2: break up the calculation into pieces. 

Back to top 


Bill Woodger
DFSORT Moderator
Joined: 09 Mar 2011 Posts: 7314




You must multiply first, divide last.
Your final action is to multiply by 100. What do you think there could possibly be to "round" after that? 

Back to top 


Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA




My mistake. I didn't realize you had a 3dimensional table. Have you read thoroughly the Appendix I mentioned? I'd break the COMPUTE statement up into individual DIVIDEs and MULTIPLYs paying close attention to the precision of the intermediate results. 

Back to top 


shalem
New User
Joined: 11 Apr 2005 Posts: 8




Thanks Terry , I will try with Break COMPUTE into individual DIVIDEs and MULTIPLYs. 

Back to top 


Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA




Hint:
When I calculate a percentage, I use the following:
Code: 
05 wssize pic s999 comp3.
05 wsmax pic s999 comp3.
05 wspart pic s9v99 comp3.
05 wspct pic zz9.
divide wssize by wsmax giving wspart rounded
multiply 100 by wspart giving wspct 
Hope this helps. 

Back to top 


Bill Woodger
DFSORT Moderator
Joined: 09 Mar 2011 Posts: 7314




Terry, you have two surplus decimal places (surplus to your final result). shalem could achieve the same in the COMPUTE by adding two redundant decimalplaces to his fields :)
shalem,
Simply rearrange your COMPUTE to do the multiplication first, and the division last.
Work your example through, existing COMPUTE and rearranged COMPUTE, with the Appendix Terry suggested earlier, and you'll see the difference in action.
If you want to split it up, that is fine, but you have to look after sizes yourself (because what is otherwise an intermediate value, you have to save for the next stage).,
You either have to make you intermediate 100 times larger than the source field (MULTIPLY first), or have the two excess decimal places (DIVIDE first).
Using COMPUTE you need neither excess size nor excess decimal places. You just have to do things in the correct order. In COPUTE, multiply, then divide, will get your result.
Code: 
COMPUTE C = ( 100 * A ) / B 
is what you want.
Algebraically that is the same as 100 * ( A / B ). It just isn't the same, because the intermediates are not like a calculator.
A = 33
B = 70
A / B = 0.47142857142857142857142857142857 with a calculator. In the intermediates (with ROUNDED you get an extra decimal place, which is how the compiler will know to round or not) it is 0.471.
When you multiply that by 100, you get 47.100, and the ROUNDED operates on the loworder digit, which is 100% guaranteed to always be zero (because of the multiply).
Multiply first, divide last, and the precision is preserved for the correct rounding. 

Back to top 


shalem
New User
Joined: 11 Apr 2005 Posts: 8




Thanks guys for your timely help. I got right value 3.0 by following your procedure. Appreciate your help. 

Back to top 


