# Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option

• 10-14-2008, 08:49 PM
unix
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:

LINE-ITEM-UNIT-PRICE = 0 (PIC S9(5)v99 COMP.)
LINE-ITEM-UNIT-COST = 0 (PIC S9(5)v999 COMP.)
STOP-TARIFF-RATE (STOP-NO) = 142.79 (PIC S9(5)v99 COMP.)
STOP-COST-RATE (STOP-NO) = 142.79 (PIC S9(5)v999 COMP.)
ORDER-TOTAL-WEIGHT = 110.23 (PIC S9(5)v99 COMP.)
OHP = 100.000(PIC S9(3)v999 COMP.)

I don't understand why the LINE-ITEM-UNIT-PRICE and LINE-ITEM-UNIT-COST
yields the following results for this COMPUTE statement using ROUNDED

COMPUTE LINE-ITEM-UNIT-PRICE ROUNDED = STOP-TARIFF-RATE (STOP-
NO) / ORDER-TOTAL-WEIGHT * OHP
ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-PRICE.

Results:
LINE-ITEM-UNIT-PRICE = 129.50

COMPUTE LINE-ITEM-UNIT-COST ROUNDED = STOP-COST-RATE (STOP-NO) /
ORDER-TOTAL-WEIGHT * OHP
ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-COST.

Results:
LINE-ITEM-UNIT-COST = 129.530

Yet, if i take the ROUNDED option out of the compute, the results are:
LINE-ITEM-UNIT-PRICE = 129.50
LINE-ITEM-UNIT-COST = 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:
LINE-ITEM-UNIT-PRICE = 129.54
LINE-ITEM-UNIT-COST = 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 [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *

• 10-14-2008, 09:14 PM
unix
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 unit-price fields with two decimal positions...just a thought....Tom

--------------------------------------------------
From: "Tony Girgenti" <tony@LAKESIDEOS.COM>
Sent: Tuesday, October 14, 2008 4:49 PM
To: <HP3000-L@RAVEN.UTC.EDU>
Subject: [HP3000-L] Cobol: Puzzled by results of COBOL Compute with and w/o
Rounded option
[color=blue]
> Hello.
>
> Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
>
> If this is true:
>
> LINE-ITEM-UNIT-PRICE = 0 (PIC S9(5)v99 COMP.)
> LINE-ITEM-UNIT-COST = 0 (PIC S9(5)v999 COMP.)
> STOP-TARIFF-RATE (STOP-NO) = 142.79 (PIC S9(5)v99 COMP.)
> STOP-COST-RATE (STOP-NO) = 142.79 (PIC S9(5)v999 COMP.)
> ORDER-TOTAL-WEIGHT = 110.23 (PIC S9(5)v99 COMP.)
> OHP = 100.000(PIC S9(3)v999 COMP.)
>
> I don't understand why the LINE-ITEM-UNIT-PRICE and LINE-ITEM-UNIT-COST
> yields the following results for this COMPUTE statement using ROUNDED
>
> COMPUTE LINE-ITEM-UNIT-PRICE ROUNDED = STOP-TARIFF-RATE (STOP-
> NO) / ORDER-TOTAL-WEIGHT * OHP
> ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-PRICE.
>
> Results:
> LINE-ITEM-UNIT-PRICE = 129.50
>
> COMPUTE LINE-ITEM-UNIT-COST ROUNDED = STOP-COST-RATE (STOP-NO) /
> ORDER-TOTAL-WEIGHT * OHP
> ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-COST.
>
> Results:
> LINE-ITEM-UNIT-COST = 129.530
>
> Yet, if i take the ROUNDED option out of the compute, the results are:
> LINE-ITEM-UNIT-PRICE = 129.50
> LINE-ITEM-UNIT-COST = 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:
> LINE-ITEM-UNIT-PRICE = 129.54
> LINE-ITEM-UNIT-COST = 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 [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *[/color]

* To join/leave the list, search archives, change list settings, *
* etc., please visit [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *

• 10-14-2008, 09:55 PM
unix
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" <tony@LAKESIDEOS.COM> wrote:[color=blue]
>Hello.
>
>Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
>
>If this is true:
>
>LINE-ITEM-UNIT-PRICE = 0 (PIC S9(5)v99 COMP.)
>LINE-ITEM-UNIT-COST = 0 (PIC S9(5)v999 COMP.)
>STOP-TARIFF-RATE (STOP-NO) = 142.79 (PIC S9(5)v99 COMP.)
>STOP-COST-RATE (STOP-NO) = 142.79 (PIC S9(5)v999 COMP.)
>ORDER-TOTAL-WEIGHT = 110.23 (PIC S9(5)v99 COMP.)
>OHP = 100.000(PIC S9(3)v999 COMP.)
>
>I don't understand why the LINE-ITEM-UNIT-PRICE and LINE-ITEM-UNIT-COST
>yields the following results for this COMPUTE statement using ROUNDED
>
>COMPUTE LINE-ITEM-UNIT-PRICE ROUNDED = STOP-TARIFF-RATE (STOP-
>NO) / ORDER-TOTAL-WEIGHT * OHP
>ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-PRICE.
>
>Results:
>LINE-ITEM-UNIT-PRICE = 129.50
>
>COMPUTE LINE-ITEM-UNIT-COST ROUNDED = STOP-COST-RATE (STOP-NO) /
>ORDER-TOTAL-WEIGHT * OHP
>ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-COST.
>
>Results:
>LINE-ITEM-UNIT-COST = 129.530
>
>Yet, if i take the ROUNDED option out of the compute, the results are:
>LINE-ITEM-UNIT-PRICE = 129.50
>LINE-ITEM-UNIT-COST = 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:
>LINE-ITEM-UNIT-PRICE = 129.54
>LINE-ITEM-UNIT-COST = 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 [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *
>
>[/color]

* To join/leave the list, search archives, change list settings, *
* etc., please visit [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *

• 10-15-2008, 01:08 AM
unix
Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
Tom Hula wrote:
[color=blue]
> 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 unit-price fields with two decimal positions...just a thought....Tom
>
> --------------------------------------------------
> From: "Tony Girgenti" <tony@LAKESIDEOS.COM>
> Sent: Tuesday, October 14, 2008 4:49 PM
> To: <HP3000-L@RAVEN.UTC.EDU>
> Subject: [HP3000-L] Cobol: Puzzled by results of COBOL Compute with and
> w/o Rounded option
>[color=green]
>> Hello.
>>
>> Using HP3000, 928rx, MPEiX 6.0, HP COBOL II 78, Minisoft WS92 emulation.
>>
>> If this is true:
>>
>> LINE-ITEM-UNIT-PRICE = 0 (PIC S9(5)v99 COMP.)
>> LINE-ITEM-UNIT-COST = 0 (PIC S9(5)v999 COMP.)
>> STOP-TARIFF-RATE (STOP-NO) = 142.79 (PIC S9(5)v99 COMP.)
>> STOP-COST-RATE (STOP-NO) = 142.79 (PIC S9(5)v999 COMP.)
>> ORDER-TOTAL-WEIGHT = 110.23 (PIC S9(5)v99 COMP.)
>> OHP = 100.000(PIC S9(3)v999 COMP.)
>>
>> I don't understand why the LINE-ITEM-UNIT-PRICE and LINE-ITEM-UNIT-COST
>> yields the following results for this COMPUTE statement using ROUNDED
>>
>> COMPUTE LINE-ITEM-UNIT-PRICE ROUNDED = STOP-TARIFF-RATE (STOP-
>> NO) / ORDER-TOTAL-WEIGHT * OHP
>> ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-PRICE.
>>
>> Results:
>> LINE-ITEM-UNIT-PRICE = 129.50
>>
>> COMPUTE LINE-ITEM-UNIT-COST ROUNDED = STOP-COST-RATE (STOP-NO) /
>> ORDER-TOTAL-WEIGHT * OHP
>> ON SIZE ERROR MOVE ZEROS TO LINE-ITEM-UNIT-COST.
>>
>> Results:
>> LINE-ITEM-UNIT-COST = 129.530
>>
>> Yet, if i take the ROUNDED option out of the compute, the results are:
>> LINE-ITEM-UNIT-PRICE = 129.50
>> LINE-ITEM-UNIT-COST = 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:
>> LINE-ITEM-UNIT-PRICE = 129.54
>> LINE-ITEM-UNIT-COST = 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 [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *[/color]
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *[/color]

(My USENet server doesn't have the original message, so I have to reply to a reply.)

Tony:

Have you tried making the variables COMP-3 instead of COMP?

• 10-15-2008, 04:48 AM
unix
Re: Cobol: Puzzled by results of COBOL Compute with and w/o Rounded option
Tony writes:

[snip]
[color=blue]
> I don't understand why the LINE-ITEM-UNIT-PRICE and[/color]
LINE-ITEM-UNIT-COST[color=blue]
> yields the following results for this COMPUTE statement using ROUNDED[/color]

[snip]
[color=blue]
> I'm not so concerned about why it is happening as much as how to make[/color]
it[color=blue]
> give the results I want.[/color]

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 [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *

• 10-15-2008, 05:00 AM
unix
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: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU] On Behalf Of Walter J. Murray
Sent: Wednesday, 15 October 2008 3:48 PM
To: [email]HP3000-L@RAVEN.UTC.EDU[/email]
Subject: Re: [HP3000-L] Cobol: Puzzled by results of COBOL Compute with andw/o Rounded option

Tony writes:

[snip]
[color=blue]
> I don't understand why the LINE-ITEM-UNIT-PRICE and[/color]
LINE-ITEM-UNIT-COST[color=blue]
> yields the following results for this COMPUTE statement using ROUNDED[/color]

[snip]
[color=blue]
> I'm not so concerned about why it is happening as much as how to make[/color]
it[color=blue]
> give the results I want.[/color]

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 [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *

* To join/leave the list, search archives, change list settings, *
* etc., please visit [url]http://raven.utc.edu/archives/hp3000-l.html[/url] *