ROUNDED Problem with COMPUTE statement

Author Message
shalem

New User

Joined: 11 Apr 2005
Posts: 8

 Posted: Thu Feb 09, 2017 8:16 pm Hi, can you please help me ROUNDED issue in COMPUTE statement AVERAGE-RATE PIC S9(3)V999 COMP-3. COMPUTE AVERAGE-RATE (S1, S2, S3) ROUNDED = (((TOP-VALUE (S1, S2, S3) / BOTTOM-VALUE (S1, S2, S3)) - 1.0) * 100). TOP VALUE/BOTTOM VALUE = 12024546.51/11674330.16= 1.029998 1.029998-1.0=0.029998 0.029998*100= 2.9998 When I gave rounded option why I am getting 2.99 instead of 3.00
Terry Heinze

JCL Moderator

Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

 Posted: Thu Feb 09, 2017 8:36 pm 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?
Terry Heinze

JCL Moderator

Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

 Posted: Thu Feb 09, 2017 8:54 pm Also, what is TOP VALUE and BOTTOM VALUE? Do you mean the Intrinsic functions MAX and MIN?
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8570
Location: Dubuque, Iowa, USA

 Posted: Thu Feb 09, 2017 8:57 pm First of all, your post is inconsistent -- if AVERAGE-RATE 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 TOP-VALUE 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.
shalem

New User

Joined: 11 Apr 2005
Posts: 8

 Posted: Thu Feb 09, 2017 9:01 pm Thanks for quick reply. Both Top and Bottom values are defined IN ARRAY TOP-VALUE PIC S9(14)V99 COMP-3. BOTTOM-VALUE PIC S9(14)V99 COMP-3. If COBOL does not carry the precision of intermediate results then what is alternate for me.
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8570
Location: Dubuque, Iowa, USA

Posted: Thu Feb 09, 2017 9:10 pm

Have you considered making TOP-VALUE and BOTTOM-VALUE 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.
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7310
Location: Inside the Matrix

 Posted: Thu Feb 09, 2017 9:12 pm 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?
Terry Heinze

JCL Moderator

Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

 Posted: Thu Feb 09, 2017 9:13 pm My mistake. I didn't realize you had a 3-dimensional 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.
shalem

New User

Joined: 11 Apr 2005
Posts: 8

 Posted: Thu Feb 09, 2017 9:17 pm Thanks Terry , I will try with Break COMPUTE into individual DIVIDEs and MULTIPLYs.
Terry Heinze

JCL Moderator

Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

Posted: Thu Feb 09, 2017 9:36 pm

Hint:
When I calculate a percentage, I use the following:
 Code: 05  ws-size  pic s999  comp-3. 05  ws-max   pic s999  comp-3. 05  ws-part  pic s9v99 comp-3. 05  ws-pct   pic  zz9. divide ws-size by ws-max giving ws-part rounded multiply 100 by ws-part giving ws-pct

Hope this helps.
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7310
Location: Inside the Matrix

Posted: Thu Feb 09, 2017 10:27 pm

Terry, you have two surplus decimal places (surplus to your final result). shalem could achieve the same in the COMPUTE by adding two redundant decimal-places 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 low-order 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.
shalem

New User

Joined: 11 Apr 2005
Posts: 8

 Posted: Thu Feb 09, 2017 11:10 pm Thanks guys for your timely help. I got right value 3.0 by following your procedure. Appreciate your help.
 View Bookmarks All times are GMT + 6 Hours

 Topic Forum Replies Similar Topics SYNCSORT/ICETOOL JOINKEYS SORT Statem... DFSORT/ICETOOL 13 problem in select max when executing ... IMS DB/DC 6 DFDSS COPY using Filter REFDT statement JCL & VSAM 2 Sysncsort - Justification problem SYNCSORT 6 SKIP LOCKED DATA in UPDATE statement DB2 9
Search our Forums:

 © 2003-2021  IBM MAINFRAMES Software & Support Division Board Rules | FAQ | Downloads | Wiki | SiteMap | Contact Us