Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option  Hewlett Packard
This is a discussion on Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option  Hewlett Packard ; Hello.
Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
If this is true:
LINEITEMUNITPRICE = 0 (PIC S9(5)v99 COMP.)
LINEITEMUNITCOST = 0 (PIC S9(5)v999 COMP.)
STOPTARIFFRATE (STOPNO) = 142.79 (PIC S9(5)v99 COMP.)
STOPCOSTRATE (STOPNO) = 142.79 ...

Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
Hello.
Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
If this is true:
LINEITEMUNITPRICE = 0 (PIC S9(5)v99 COMP.)
LINEITEMUNITCOST = 0 (PIC S9(5)v999 COMP.)
STOPTARIFFRATE (STOPNO) = 142.79 (PIC S9(5)v99 COMP.)
STOPCOSTRATE (STOPNO) = 142.79 (PIC S9(5)v999 COMP.)
ORDERTOTALWEIGHT = 110.23 (PIC S9(5)v99 COMP.)
OHP = 100.000(PIC S9(3)v999 COMP.)
I don't understand why the LINEITEMUNITPRICE and LINEITEMUNITCOST
yields the following results for this COMPUTE statement using ROUNDED
COMPUTE LINEITEMUNITPRICE ROUNDED = STOPTARIFFRATE (STOP
NO) / ORDERTOTALWEIGHT * OHP
ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITPRICE.
Results:
LINEITEMUNITPRICE = 129.50
COMPUTE LINEITEMUNITCOST ROUNDED = STOPCOSTRATE (STOPNO) /
ORDERTOTALWEIGHT * OHP
ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITCOST.
Results:
LINEITEMUNITCOST = 129.530
Yet, if i take the ROUNDED option out of the compute, the results are:
LINEITEMUNITPRICE = 129.50
LINEITEMUNITCOST = 129.500
If i multiply this out on a calculator:
142.79 / 110.23 * 100.000 = 129.5382
My puzzlement lies in the mystery of why a ROUNDED option causes less
rounding than a COMPUTE without the ROUNDED option.
I'm more concerned about finding out a way to get the answer of:
LINEITEMUNITPRICE = 129.54
LINEITEMUNITCOST = 129.538
I'm not so concerned about why it is happening as much as how to make it
give the results I want.
Any help would be gratefully appreciated.
Thanks,
Tony
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000l.html *

Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
I wonder what would happen if you specified 3 decimal positions
throughout...you might be losing some
significance using a mixture of decimal sizes...using temporary fields and
then moving the end result to
the unitprice fields with two decimal positions...just a thought....Tom

From: "Tony Girgenti"
Sent: Tuesday, October 14, 2008 4:49 PM
To:
Subject: [HP3000L] Cobol: Puzzled by results of COBOL Compute with and w/o
Rounded option
> Hello.
>
> Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
>
> If this is true:
>
> LINEITEMUNITPRICE = 0 (PIC S9(5)v99 COMP.)
> LINEITEMUNITCOST = 0 (PIC S9(5)v999 COMP.)
> STOPTARIFFRATE (STOPNO) = 142.79 (PIC S9(5)v99 COMP.)
> STOPCOSTRATE (STOPNO) = 142.79 (PIC S9(5)v999 COMP.)
> ORDERTOTALWEIGHT = 110.23 (PIC S9(5)v99 COMP.)
> OHP = 100.000(PIC S9(3)v999 COMP.)
>
> I don't understand why the LINEITEMUNITPRICE and LINEITEMUNITCOST
> yields the following results for this COMPUTE statement using ROUNDED
>
> COMPUTE LINEITEMUNITPRICE ROUNDED = STOPTARIFFRATE (STOP
> NO) / ORDERTOTALWEIGHT * OHP
> ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITPRICE.
>
> Results:
> LINEITEMUNITPRICE = 129.50
>
> COMPUTE LINEITEMUNITCOST ROUNDED = STOPCOSTRATE (STOPNO) /
> ORDERTOTALWEIGHT * OHP
> ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITCOST.
>
> Results:
> LINEITEMUNITCOST = 129.530
>
> Yet, if i take the ROUNDED option out of the compute, the results are:
> LINEITEMUNITPRICE = 129.50
> LINEITEMUNITCOST = 129.500
>
> If i multiply this out on a calculator:
> 142.79 / 110.23 * 100.000 = 129.5382
>
> My puzzlement lies in the mystery of why a ROUNDED option causes less
> rounding than a COMPUTE without the ROUNDED option.
>
> I'm more concerned about finding out a way to get the answer of:
> LINEITEMUNITPRICE = 129.54
> LINEITEMUNITCOST = 129.538
>
> I'm not so concerned about why it is happening as much as how to make it
> give the results I want.
>
> Any help would be gratefully appreciated.
>
> Thanks,
> Tony
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000l.html *

Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
HI Tony 
I believe you have a precision problem, and it is made a little worse by rounding. Try making all the variable the same length
(i.e. S9(5)v9(3)). You might want to add a couple extra places for better precision as well. Just remember to move them to an
appropriate display variable when your do.
Yours,
Paul
On Tuesday, October 14, 2008, at 01:49PM, "Tony Girgenti" wrote:
>Hello.
>
>Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
>
>If this is true:
>
>LINEITEMUNITPRICE = 0 (PIC S9(5)v99 COMP.)
>LINEITEMUNITCOST = 0 (PIC S9(5)v999 COMP.)
>STOPTARIFFRATE (STOPNO) = 142.79 (PIC S9(5)v99 COMP.)
>STOPCOSTRATE (STOPNO) = 142.79 (PIC S9(5)v999 COMP.)
>ORDERTOTALWEIGHT = 110.23 (PIC S9(5)v99 COMP.)
>OHP = 100.000(PIC S9(3)v999 COMP.)
>
>I don't understand why the LINEITEMUNITPRICE and LINEITEMUNITCOST
>yields the following results for this COMPUTE statement using ROUNDED
>
>COMPUTE LINEITEMUNITPRICE ROUNDED = STOPTARIFFRATE (STOP
>NO) / ORDERTOTALWEIGHT * OHP
>ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITPRICE.
>
>Results:
>LINEITEMUNITPRICE = 129.50
>
>COMPUTE LINEITEMUNITCOST ROUNDED = STOPCOSTRATE (STOPNO) /
>ORDERTOTALWEIGHT * OHP
>ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITCOST.
>
>Results:
>LINEITEMUNITCOST = 129.530
>
>Yet, if i take the ROUNDED option out of the compute, the results are:
>LINEITEMUNITPRICE = 129.50
>LINEITEMUNITCOST = 129.500
>
>If i multiply this out on a calculator:
>142.79 / 110.23 * 100.000 = 129.5382
>
>My puzzlement lies in the mystery of why a ROUNDED option causes less
>rounding than a COMPUTE without the ROUNDED option.
>
>I'm more concerned about finding out a way to get the answer of:
>LINEITEMUNITPRICE = 129.54
>LINEITEMUNITCOST = 129.538
>
>I'm not so concerned about why it is happening as much as how to make it
>give the results I want.
>
>Any help would be gratefully appreciated.
>
>Thanks,
>Tony
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000l.html *
>
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000l.html *

Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
Tom Hula wrote:
> I wonder what would happen if you specified 3 decimal positions
> throughout...you might be losing some
> significance using a mixture of decimal sizes...using temporary fields and
> then moving the end result to
> the unitprice fields with two decimal positions...just a thought....Tom
>
> 
> From: "Tony Girgenti"
> Sent: Tuesday, October 14, 2008 4:49 PM
> To:
> Subject: [HP3000L] Cobol: Puzzled by results of COBOL Compute with and
> w/o Rounded option
>
>> Hello.
>>
>> Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
>>
>> If this is true:
>>
>> LINEITEMUNITPRICE = 0 (PIC S9(5)v99 COMP.)
>> LINEITEMUNITCOST = 0 (PIC S9(5)v999 COMP.)
>> STOPTARIFFRATE (STOPNO) = 142.79 (PIC S9(5)v99 COMP.)
>> STOPCOSTRATE (STOPNO) = 142.79 (PIC S9(5)v999 COMP.)
>> ORDERTOTALWEIGHT = 110.23 (PIC S9(5)v99 COMP.)
>> OHP = 100.000(PIC S9(3)v999 COMP.)
>>
>> I don't understand why the LINEITEMUNITPRICE and LINEITEMUNITCOST
>> yields the following results for this COMPUTE statement using ROUNDED
>>
>> COMPUTE LINEITEMUNITPRICE ROUNDED = STOPTARIFFRATE (STOP
>> NO) / ORDERTOTALWEIGHT * OHP
>> ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITPRICE.
>>
>> Results:
>> LINEITEMUNITPRICE = 129.50
>>
>> COMPUTE LINEITEMUNITCOST ROUNDED = STOPCOSTRATE (STOPNO) /
>> ORDERTOTALWEIGHT * OHP
>> ON SIZE ERROR MOVE ZEROS TO LINEITEMUNITCOST.
>>
>> Results:
>> LINEITEMUNITCOST = 129.530
>>
>> Yet, if i take the ROUNDED option out of the compute, the results are:
>> LINEITEMUNITPRICE = 129.50
>> LINEITEMUNITCOST = 129.500
>>
>> If i multiply this out on a calculator:
>> 142.79 / 110.23 * 100.000 = 129.5382
>>
>> My puzzlement lies in the mystery of why a ROUNDED option causes less
>> rounding than a COMPUTE without the ROUNDED option.
>>
>> I'm more concerned about finding out a way to get the answer of:
>> LINEITEMUNITPRICE = 129.54
>> LINEITEMUNITCOST = 129.538
>>
>> I'm not so concerned about why it is happening as much as how to make it
>> give the results I want.
>>
>> Any help would be gratefully appreciated.
>>
>> Thanks,
>> Tony
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000l.html *
(My USENet server doesn't have the original message, so I have to reply to a reply.)
Tony:
Have you tried making the variables COMP3 instead of COMP?

Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
Tony writes:
[snip]
> I don't understand why the LINEITEMUNITPRICE and
LINEITEMUNITCOST
> yields the following results for this COMPUTE statement using ROUNDED
[snip]
> I'm not so concerned about why it is happening as much as how to make
it
> give the results I want.
The short answer is, when using a COMPUTE statement that involves
division, arrange the arithmetic expression so that the division will be
the last operation performed.
When you use a COMPUTE statement, you are throwing yourself on the mercy
of the compiler to decide how many decimal places to use for
intermediate results. If you ever port this code to a different
platform or a different compiler, expect to get different results.
The safest, and most portable, technique is to avoid the COMPUTE
statement and stick with ADD, SUBTRACT, MULTIPLY, and DIVIDE. Then you
get to control the precision of intermediate results, and the COBOL
language guarantees what the result will be.
Walter
Walter J. Murray
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000l.html *

Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
And to make it plainer whats going on , do each operation in a single step,so you can debug it with display statements readily if the need arises.
In fact, split your compute up into discrete steps with a display stmt after each showing the intermediate results, and then do it again with the divide last, and check the differences out.
jp
Original Message
From: HP3000 Systems Discussion [mailto:HP3000L@RAVEN.UTC.EDU] On Behalf Of Walter J. Murray
Sent: Wednesday, 15 October 2008 3:48 PM
To: HP3000L@RAVEN.UTC.EDU
Subject: Re: [HP3000L] Cobol: Puzzled by results of COBOL Compute with andw/o Rounded option
Tony writes:
[snip]
> I don't understand why the LINEITEMUNITPRICE and
LINEITEMUNITCOST
> yields the following results for this COMPUTE statement using ROUNDED
[snip]
> I'm not so concerned about why it is happening as much as how to make
it
> give the results I want.
The short answer is, when using a COMPUTE statement that involves
division, arrange the arithmetic expression so that the division will be
the last operation performed.
When you use a COMPUTE statement, you are throwing yourself on the mercy
of the compiler to decide how many decimal places to use for
intermediate results. If you ever port this code to a different
platform or a different compiler, expect to get different results.
The safest, and most portable, technique is to avoid the COMPUTE
statement and stick with ADD, SUBTRACT, MULTIPLY, and DIVIDE. Then you
get to control the precision of intermediate results, and the COBOL
language guarantees what the result will be.
Walter
Walter J. Murray
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000l.html *