Inaccurate math results in Micro Focus Unix

[eselick]

Hi

The following formula gives $5.88/hr in MF cobol V3.2 on Unix which is incorrect.

COMPUTE WS-DOL-HR ROUNDED = WS-DOL-ERN / WS-HRS-WRK

Initial values:

WS-HRS-WRK = .0833333
WS-DOL-ERN = .49

Working storage:

77 WS-HRS-WRK PIC 9(2)V9(6) COMP.
77 WS-DOL-HR PIC 9(2)V9(2) COMP.
77 WS-DOL-ERN PIC 9V9(2) COMP.


The same formula in Excel gives $5.93/hr which is the correct answer.

This is only happening when dol-ern is very small.

Thanks for any ideas.

E.

[Rick Smith]

.0833333 requires a PIC of 9(2)V9(7).

Both Windows Calculator and Excel 2010 give 5.88, on my system.

That suggests either there is a problem with the Excel being
used or the formula as used in Excel.

[elli...@gmail.com]

Hi Rick
I've figured out what's happening. In fact, the real dollars earned is .49425.

This is calculated by multiplying 5.93 by 5 minutes worked or .083333 in decimal hours but the precision was lost by the time I did my formula.

I was misled in Excel even when I redid it the calculation because I had the output formatted as $, so it displayed as $.49, however internally is was using the extra decimals and got 5.93

When I just keyed in .49 it did get 5.88 as you said. The formatting got me!!

Duh !!.

It's a business problem since people are not paid in dollars to 4 decimal places, so the accuracy is lost.

Thanks for engaging in the dialog

Elliot

[Rick Smith]

On Saturday, May 11, 2013 8:19:42 AM UTC-4, elli...@gmail.com wrote:
[snip]

> Thanks for engaging in the dialog

And thank you for providing the resolution to the problem.

[Pete Dashwood]

I learned a long time ago that for dealing with currency in COBOL a picture
with 4 decimal places avoids rounding problems.

When obtaining currency data from other systems like Excel or Access store
it into COBOL as PIC S9(14)v9(4).

Obviously when it is formatted for output only 2 places are shown.

Saves a lot of head scratching...

Pete.


--
"I used to write COBOL...now I can do anything."

[Doug Miller]

eselick <ese...@gmail.com> wrote in news:599b5508-65a7-43df-bc9f-0b92c1e511d9
@googlegroups.com:

> Hi
>
> The following formula gives $5.88/hr in MF cobol V3.2 on Unix which is incorrect.
>
> COMPUTE WS-DOL-HR ROUNDED = WS-DOL-ERN / WS-HRS-WRK
>
> Initial values:
>
> WS-HRS-WRK = .0833333
> WS-DOL-ERN = .49
>
> Working storage:
>
> 77 WS-HRS-WRK PIC 9(2)V9(6) COMP.
> 77 WS-DOL-HR PIC 9(2)V9(2) COMP.
> 77 WS-DOL-ERN PIC 9V9(2) COMP.
>
>
> The same formula in Excel gives $5.93/hr which is the correct answer.

No, it is not. Do it with pencil and paper, or pick up a calculator, and you will see that the
correct answer is indeed 5.88, not 5.93.

[Pete Trashwood]

On 2013-05-12, Doug Miller <doug_at_mil...@example.com> wrote:
> eselick <ese...@gmail.com> wrote in news:599b5508-65a7-43df-bc9f-0b92c1e511d9
> @googlegroups.com:
>
>> Hi
>>
>> The following formula gives $5.88/hr in MF cobol V3.2 on Unix which is incorrect.

I'm going with Doug on this one. It sure looks correct to me.

>> Working storage:
>>
>> 77 WS-HRS-WRK PIC 9(2)V9(6) COMP.
>> 77 WS-DOL-HR PIC 9(2)V9(2) COMP.
>> 77 WS-DOL-ERN PIC 9V9(2) COMP.

Does your compiler not have packed decimal support? Doing money calcs in
binary is a sure way to get your incompetent ass fired. I wouldn't want to
be you.

>> The same formula in Excel gives $5.93/hr which is the correct answer.
>
> No, it is not. Do it with pencil and paper, or pick up a calculator, and you will see that the
> correct answer is indeed 5.88, not 5.93.

Yep it sure is and I have some serious questions about this guy and how he
got this job.

[Pete Dashwood]

You are obviously no relation to me.

I post under my own name because I have the courage of my convictions, and I
don't need to hide behind an alias.

I also accept that some people will be pissed off with my posts but most of
them also have the balls to say so to my face.

[Doug Miller]

"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in news:avar7bFslqoU1
@mid.individual.net:

Nevertheless, his point is valid: doing money calculations in binary *is* a very bad idea.

[Richard]

On May 13, 4:28 am, Pete Trashwood <peteisinth...@trashwood.com>
wrote:

> On 2013-05-12, Doug Miller <doug_at_milmac_dot_...@example.com> wrote:
>
> >> Working storage:
>
> >>        77  WS-HRS-WRK                  PIC 9(2)V9(6) COMP.
> >>        77  WS-DOL-HR                   PIC 9(2)V9(2) COMP.
> >>        77  WS-DOL-ERN                  PIC 9V9(2)    COMP.
>
> Does your compiler not have packed decimal support? Doing money calcs in
> binary is a sure way to get your incompetent ass fired. I wouldn't want to
> be you.

For COBOL there is no difference at all in the results of calculations
when the fields are COMP, BINARY, COMP-5, PACKED, or DISPLAY NUMERIC,
or any combination. There may be tiny differences in the speed.

The only significant difference is the storage format and size.

It is not like floating point real was specified.

The incompetence in COBOL is yours.

> >> The same formula in Excel gives $5.93/hr which is the correct answer.
>
> > No, it is not. Do it with pencil and paper, or pick up a calculator, and you will see that the
> > correct answer is indeed 5.88, not 5.93.
>
> Yep it sure is and I have some serious questions about this guy and how he
> got this job.

The serious question is why anyone would use Excel.

[Richard]

On May 13, 12:57 pm, Doug Miller <doug_at_milmac_dot_...@example.com>
wrote:
> "Pete Dashwood" <dashw...@removethis.enternet.co.nz> wrote in news:avar7bFslqoU1
> @mid.individual.net:
>
>
>
>
>
>
>
>
>
> > Pete Trashwood wrote:
> >> On 2013-05-12, Doug Miller <doug_at_milmac_dot_...@example.com> wrote:
> >>> eselick <esel...@gmail.com> wrote in

Complete nonsense.

[Robert Wessel]

To agree with Richard: completely wrong.

Currency calculations need to be done in properly scaled (almost
always decimal scaled) fixed point arithmetic. *FP* is certainly a
bad idea most of the time.

Decimal scaling is somewhat more convenient if you have decimal
arithmetic facilities, but that's, and the greater similarity to some
I/O formats are only advantages.

In fact the Cobol spec doesn't specify the internal representation*,
but it does specify the results of arithmetic operations. Any
fiddling needed to accomplish that is the job of the compiler, and the
result of:

01 A PIC 9(9)v9(3) USAGE x.
01 B PIC 9(5)v9(6) USAGE x.
01 C PIC 9(10)v9(4) USAGE x.

COMPUTE C = A * B.

is the same if USAGE specifies a display binary or decimal format.

Again, doing currency in floating point is bad idea.


*OK, these days it does get into that a bit, but it didn't used to,
and what COMP-x actually meant was quite undefined.

[Pete Dashwood]

Yes it is, but why didn't you say that under your own name? Do you seriously
think I don't have the capability to trace your mail?

Doug, we have had differences in the past but I never expected you to resort
to trashing the family name. If you have an issue with me, have it with me,
not my family.

I bear you no malice despite the disrespect you have shown, but that says
more about you than it does about me.

[Pete Dashwood]

A very good point.

As stated previously, I use PIC s9(14)v9(4) for currency and have never had
a problem.

[Pete Dashwood]

Richard wrote:
> On May 13, 4:28 am, Pete Trashwood <peteisinth...@trashwood.com>
> wrote:
>> On 2013-05-12, Doug Miller <doug_at_milmac_dot_...@example.com>
>> wrote:
>>
>>>> Working storage:
>>
>>>> 77 WS-HRS-WRK PIC 9(2)V9(6) COMP.
>>>> 77 WS-DOL-HR PIC 9(2)V9(2) COMP.
>>>> 77 WS-DOL-ERN PIC 9V9(2) COMP.
>>
>> Does your compiler not have packed decimal support? Doing money
>> calcs in binary is a sure way to get your incompetent ass fired. I
>> wouldn't want to be you.
>
> For COBOL there is no difference at all in the results of calculations
> when the fields are COMP, BINARY, COMP-5, PACKED, or DISPLAY NUMERIC,
> or any combination. There may be tiny differences in the speed.
>
> The only significant difference is the storage format and size.

Exactly. COBOL does a great job of converting and scaling.

>
> It is not like floating point real was specified.
>
> The incompetence in COBOL is yours.
>
>
>>>> The same formula in Excel gives $5.93/hr which is the correct
>>>> answer.
>>
>>> No, it is not. Do it with pencil and paper, or pick up a
>>> calculator, and you will see that the correct answer is indeed
>>> 5.88, not 5.93.
>>
>> Yep it sure is and I have some serious questions about this guy and
>> how he got this job.
>
> The serious question is why anyone would use Excel.

Millions of people use Excel every day and not only find it useful, but also
get it right. I think the OP was fair and open about his mistake and
explained how he got it wrong. It wasn't Excel that was wrong here.

[Bill Gunshannon]

In article <avbhp4...@mid.individual.net>,

Glad to see the "s". :-) My last gig involved a bunch of programs
that computed parts and labor costs and everyone was so proud of the
fact that according to their reports estimating was so good they
never went over the amounts they estimated.

That is they never did until I got there and found none of the
intermediate results had signs so as soon as the budget went
negative, presto, it was positive again!! :-) Oh yeah, these
programs had been running for nigh on to 30 years like that. Sigh....

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Alistair Maclean]

> > The serious question is why anyone would use Excel.

> Millions of people use Excel every day and not only find it useful, but also get it right. I think the OP was fair and open about his mistake and explained how he got it wrong. It wasn't Excel that was wrong here.

I use Excel extensively but if you look up Louise Pryor's Excel Archives you will find enough reasons to mistrust peoples' use of Excel:

http://www.louisepryor.com/tag/spreadsheet-errors/

[Charles Hottel]

"Alistair Maclean" <alistair.j...@gmail.com> wrote in message
news:a6b4e50e-5607-4582...@googlegroups.com...

Just about any tool can be misused. That is not necessarily the tool's
fault. People need to learn to use their tools properly and with in their
applicable limits.

[Pete Dashwood]

It's olde tyme mainframe programming, as I'm sure you know, Bill.

If you don't put a sign on it, extra logical OR instructions are generated
to force a positive sign. There was a time, back in the mists of antiquity,
when EVERY extra instruction generated had to be considered... Thankfully,
those days are gone. Nowadays we use a sign because of functionality and not
especially for efficiency.

> My last gig involved a bunch of programs
> that computed parts and labor costs and everyone was so proud of the
> fact that according to their reports estimating was so good they
> never went over the amounts they estimated.
>
> That is they never did until I got there and found none of the
> intermediate results had signs so as soon as the budget went
> negative, presto, it was positive again!! :-) Oh yeah, these
> programs had been running for nigh on to 30 years like that. Sigh....

It's amazing, isn't it? Passed all the test plans, went live and everybody
"believes" in it...

[Pete Dashwood]

OR, if you spend time working with computers, you will find many reasons to
mistrust people's use of them, too :-)

[Pete Dashwood]

As someone who produces tools, all I can say is: "Amen to that!"

[Alistair Maclean]

On Monday, 13 May 2013 18:21:13 UTC+1, Charles Hottel wrote:
>> Millions of people use Excel every day and not only find it useful, but
>> also get it right. I think the OP was fair and open about his mistake and >> explained how he got it wrong. It wasn't Excel that was wrong here.

Alistair Maclean wrote:
> I use Excel extensively but if you look up Louise Pryor's Excel Archives >
> you will find enough reasons to mistrust peoples' use of Excel:
> http://www.louisepryor.com/tag/spreadsheet-errors/

CH wrote:
> Just about any tool can be misused. That is not necessarily the tool's
> fault. People need to learn to use their tools properly and with in
> their applicable limits.

And in reply:
I was not criticising the tool but the lack of skill and rigour in the application and verification of the results of using that tool by those who use the tool naively believing that they are capable programmers.

[Alistair Maclean]

On Tuesday, 14 May 2013 00:11:42 UTC+1, Pete Dashwood wrote:
> OR, if you spend time working with computers, you will find many reasons to
> mistrust people's use of them, too :-)

I have encountered the phrase "it's been produced by a computer so it must be true".

[Pete Dashwood]

Marshall MacLuhan famously said (back in the 1960s): "The media is the
message."

I once did an experiement (and nearly got fired for it) where I caused the
figures in an account summary program to be ridiculously wrong. The green
lineflo was subsequently presented to Directors and there was much wailing
and gnashing of teeth...

ONLY ONE guy actually said:"This is insane, the computer must be wrong." The
rest of them figured that if it was on green lineflo, it must be true.

I retained my job by the skin of my teeth because I was in my early 20s and
my Boss wrote it off as a prank (which in a way it was), but it was made
clear to me that such behaviour in the future would not be tolerated. (so
much for my plans to produce the next lot of summaries in Roman numerals...)

[Alistair Maclean]

On Wednesday, 15 May 2013 00:41:22 UTC+1, Pete Dashwood wrote:
> so much for my plans to produce the next lot of summaries in Roman
> numerals...)

Yeah, like that. :-)

Did you ever write the (Cobol) code to do it? Roman numerals have been blamed for the demise of their empire. Does anyone know if the Romans ever had any great mathematicians?

[Pete Dashwood]

Alistair Maclean wrote:
> On Wednesday, 15 May 2013 00:41:22 UTC+1, Pete Dashwood wrote:
>> so much for my plans to produce the next lot of summaries in Roman
>> numerals...)
>
> Yeah, like that. :-)
>
> Did you ever write the (Cobol) code to do it?

No, but it really wouldn't be hard.

> Roman numerals have
> been blamed for the demise of their empire. Does anyone know if the
> Romans ever had any great mathematicians?

They had no zero.

I've often wondered about that. Not sure if it was a conceptual flaw or they
just figured if you had nothing you didn't need to represent it.

Maybe some math historian can elucidate?

[docd...@panix.com]

In article <373f103c-ffb9-4939...@googlegroups.com>,

Alistair Maclean <alistair.j...@gmail.com> wrote:
>On Monday, 13 May 2013 18:21:13 UTC+1, Charles Hottel wrote:

[snip]

>Alistair Maclean wrote:

[snip]

>CH wrote:

[snip]

>And in reply:

[snip]

Your diligent work is noticed and appreciated, Mr Maclean.

DD

[Fred Mobach]

Pete Dashwood wrote:

> Alistair Maclean wrote:
>> On Wednesday, 15 May 2013 00:41:22 UTC+1, Pete Dashwood wrote:
>>> so much for my plans to produce the next lot of summaries in Roman
>>> numerals...)
>>
>> Yeah, like that. :-)
>>
>> Did you ever write the (Cobol) code to do it?
>
> No, but it really wouldn't be hard.
>
>> Roman numerals have
>> been blamed for the demise of their empire. Does anyone know if the
>> Romans ever had any great mathematicians?
>
> They had no zero.
>
> I've often wondered about that. Not sure if it was a conceptual flaw
> or they just figured if you had nothing you didn't need to represent
> it.

Romans were famous for engineering but not for mathematics as they
seemed to prefer practice instead of theory (which they left for the
Greeks).
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..

[Robert Wessel]

A decent overview of the history is at:

http://en.wikipedia.org/wiki/0_(number)

[Charles Hottel]

"Alistair Maclean" <alistair.j...@gmail.com> wrote in message

news:9f8cb2bb-959a-44ed...@googlegroups.com...

In college I wrote a program that manipulated (I don't remember the details
but I think I still have the listing) Roman numerials. It was written in
SNOBOL IV.

[Pete Dashwood]

Thanks Robert.

The link as posted didn't work because the closing parenthesis was not
included in the link.

However, it was pretty easy to redirect to the correct page and I found it
interetsing.

Cheers,

[Pete Dashwood]

Whenever I see a reference to SNOBOL I get an image of a computer programmer
with his nose in the air (snob) :-)

I know in the US they pronounce it like "snowball" but that isn't apparent
from seeing it written down...

[Alistair Maclean]

On Wednesday, 15 May 2013 14:12:56 UTC+1, docd...@panix.com wrote:
> Your diligent work is noticed and appreciated, Mr Maclean. DD

Thanks. I am trying (very) so please forgive any recidivism.

[Alistair Maclean]

On Wednesday, 15 May 2013 23:38:56 UTC+1, Charles Hottel wrote:
> In college I wrote a program that manipulated (I don't remember the details
> but I think I still have the listing) Roman numerials. It was written in
> SNOBOL IV.

Ah, a language named after Lisa Simpson's cat.

Does SNOBOL bear any relation to COBOL?

[Bill Gunshannon]

In article <37ce1c8c-7c33-4ead...@googlegroups.com>,

None whatsoever.

[Rick Smith]

On Thursday, May 16, 2013 3:01:35 PM UTC-4, Alistair Maclean wrote:
[snip]

> Does SNOBOL bear any relation to COBOL?

Not as a language, however Micro Focus used SNOBOL in 1976
to produce a working COBOL compiler.

"The development of the COBOL compilers began with an extremely
simple COBOL compiler, for internal use, written in the Snobol
language. This compiler accepted only a small sub-set of COBOL,
but this was sufficient to compile a more advanced version of
COBOL. By repeatedly using the current COBOL compiler to compile
a more advanced version, a compiler suitable for marketing was
produced. ..."

[Pete Dashwood]

I note in passing (as one of the little coincidences that the Universe never
ceases to amaze me with) that Yeardley Smith (the French born American
actress who is the voice of Lisa Simpson) will be attending the Armageddon
Expo in Hamilton, NZ (a little over an hour's drive from where I am writing
this) tomorrow, Saturday. I almost went but I have some other things to do
this weekend. A good friend of mine is going to both the Hamilton and
Wellington conventions and she tells me they are always worth a visit. (She
writes Fantasy stories for kids so it is a chance to promote her work).

[Richard]

My understanding is that in 1976 the founders of Microfocus were
working for ICL DataSkill in Bridge House, Reading writing a subset
COBOL compiler and runtime system for the ICL 1500 (ex Cogar/Singer)
desktop networked computers.

Later they formed MF and released a much upgraded system as CIS COBOL.

I still have some 1500s here somewhere and a manual for the COBOL
subset. There are probably some mini-tapes with this software here,
but condition completely unknown. CIS COBOL was later implemented for
ICL on the DRS20 system which replaced the 1500 series. I still have
some DRS20s here too, Models 10, 20, 40, 50. I used CIS COBOL
extensively on DRS20, CP/M and Concrrent-CP/M-86 (and later).

[Charles Hottel]

"Alistair Maclean" <alistair.j...@gmail.com> wrote in message

news:37ce1c8c-7c33-4ead...@googlegroups.com...

Not really, it is/was primarily a string manipulation language.

[Rick Smith]

My source is: Alan D. T. Fryer, "COBOL on Microcomputers", 1984.
Fryer was a member of, and represented Micro Focus on, the CODASYL
COBOL Committee. I got the book when I purchased Personal COBOL 1.0.
In Appendix G, "History of Micro Focus", he writes, "Micro Focus was
founded in 1976 in England by Brian Reynolds and Paul O'Grady."

What it does not say is where the SNOBOL interpreter was located.
It may have been on an ICL machine or C/PM or some other. I did
make the modest assumption that, having founded Micro Focus in 1976,
they began developing with SNOBOL the same year.

[Alistair Maclean]

Thanks Bill. Curiousity killed the cat but satisfaction....

Bill Gunshannon wrote:
> > AJM wrote: Does SNOBOL bear any relation to COBOL?
> None whatsoever. bill

[Alistair Maclean]

Reminds me of some of the blurb for UFO (a 4GL called User Files Online) which said that it had been written by using UFO (a previous version).

[Alistair Maclean]

On Friday, 17 May 2013 00:41:08 UTC+1, Pete Dashwood wrote:
> I note in passing (as one of the little coincidences that the Universe
> never ceases to amaze me with) that Yeardley Smith (the French born
> American actress who is the voice of Lisa Simpson) will be attending

> the Armageddon Expo in Hamilton, NZ.

I've never dragged my self to any fan fest but was amused to see the news item about Star Wars fans fighting with Dr Who Fans:

http://www.bbc.co.uk/news/uk-england-norfolk-22542222

[Alistair Maclean]

On Friday, 17 May 2013 04:53:48 UTC+1, Charles Hottel wrote:
> > Does SNOBOL bear any relation to COBOL?
> Not really, it is/was primarily a string manipulation language.

Thanks to all who responded to my query.

[Clark F Morris]

On Sun, 12 May 2013 22:13:58 -0500, Robert Wessel
<robert...@yahoo.com> wrote:

>On Mon, 13 May 2013 00:57:11 +0000 (UTC), Doug Miller
><doug_at_mil...@example.com> wrote:
>
>>"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in news:avar7bFslqoU1
>>@mid.individual.net:
>>
>>> Pete Trashwood wrote:
>>>> On 2013-05-12, Doug Miller <doug_at_mil...@example.com> wrote:
>>>>> eselick <ese...@gmail.com> wrote in
>>>>> news:599b5508-65a7-43df-bc9f-0b92c1e511d9 @googlegroups.com:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> The following formula gives $5.88/hr in MF cobol V3.2 on Unix which
>>>>>> is incorrect.
>>>>
>>>> I'm going with Doug on this one. It sure looks correct to me.
>>>>
>>>>>> Working storage:
>>>>>>
>>>>>> 77 WS-HRS-WRK PIC 9(2)V9(6) COMP.
>>>>>> 77 WS-DOL-HR PIC 9(2)V9(2) COMP.
>>>>>> 77 WS-DOL-ERN PIC 9V9(2) COMP.
>>>>
>>>> Does your compiler not have packed decimal support? Doing money calcs
>>>> in binary is a sure way to get your incompetent ass fired. I wouldn't
>>>> want to be you.
>>>>
>>>>>> The same formula in Excel gives $5.93/hr which is the correct
>>>>>> answer.
>>>>>
>>>>> No, it is not. Do it with pencil and paper, or pick up a calculator,
>>>>> and you will see that the correct answer is indeed 5.88, not 5.93.
>>>>
>>>> Yep it sure is and I have some serious questions about this guy and
>>>> how he got this job.
>>>
>>> You are obviously no relation to me.
>>>
>>> I post under my own name because I have the courage of my convictions, and I
>>> don't need to hide behind an alias.
>>>
>>> I also accept that some people will be pissed off with my posts but most of
>>> them also have the balls to say so to my face.
>>>
>>> Pete.
>>>
>>Nevertheless, his point is valid: doing money calculations in binary *is* a very bad idea.
>
>
>To agree with Richard: completely wrong.
>
>Currency calculations need to be done in properly scaled (almost
>always decimal scaled) fixed point arithmetic. *FP* is certainly a
>bad idea most of the time.
>
>Decimal scaling is somewhat more convenient if you have decimal
>arithmetic facilities, but that's, and the greater similarity to some
>I/O formats are only advantages.
>
>In fact the Cobol spec doesn't specify the internal representation*,
>but it does specify the results of arithmetic operations. Any
>fiddling needed to accomplish that is the job of the compiler, and the
>result of:
>
> 01 A PIC 9(9)v9(3) USAGE x.
> 01 B PIC 9(5)v9(6) USAGE x.
> 01 C PIC 9(10)v9(4) USAGE x.
>
> COMPUTE C = A * B.
>
>is the same if USAGE specifies a display binary or decimal format.
>
>Again, doing currency in floating point is bad idea.
>
That depends. If your COBOL has the new IEEE decimal floating point
(which the IBM z series COBOL doesn't despite Mike Cowlishaw having
played a major role in developing it while he was still at IBM and
working as an IBM fellow), it is designed for financial transactions
and supports multiple forms of rounding including rounding half to the
nearest even - 6.5 and 5.5 both round to 6. The failure by IBM COBOL
to support the IEEE floating point and the decimal floating point
despite the fact that Java supports them and IBM COBOL OO is to
support interface with Java is something that baffles and angers me.

Clark Morris
>
>*OK, these days it does get into that a bit, but it didn't used to,
>and what COMP-x actually meant was quite undefined.

[Robert Wessel]

Sort-of. IEEE decimal math is defined in such a way so that results
largely avoid the "floating" aspect of FP numbers so long as you keep
the results in range.

So IEEE decimal float is OK for currency calculations so long as you
don't actually let the numbers float... But the 128-bit format is big
enough that you can use it that way much of the time.

Still, I'm of the opinion that decimal hardware of any sort is mostly
a waste (some decimal to/from binary conversion support would probably
be worthwhile)), and just converting to fixed point binary and doing
the decimal scaling there is fast enough. (Old) packed decimal
arithmetic on Z is slow enough that it's likely to be faster to go the
binary route for all but the most trivial calculations. The decimal
FP looks to be pretty fast, though. But the actual amount of decimal
math that's done is now such a small fraction of CPUs spend time on, I
just don't see the value of a bunch of dedicated hardware.

And I acknowledge that some people disagree with me on that, but the
general computing community does not. The only meaningful decimal
support is packed on Z, and decimal FP on POWER and Z. Literally
nobody else has much worth noting.

BTW, IEEE binary FP has supported round to even (as the default) since
day one, so that's not exactly new with decimal FP, although the
implications of rounding a binary fraction are obviously different
than rounding a decimal fraction.

[robin....@gmail.com]

On Saturday, May 11, 2013 8:54:01 PM UTC+10, eselick wrote:
> Hi The following formula gives $5.88/hr in MF cobol V3.2 on Unix which
> is incorrect.

What calculator are you using?
The correct answer IS 5.88.

> COMPUTE WS-DOL-HR ROUNDED = WS-DOL-ERN / WS-HRS-WRK Initial values: WS-HRS-WRK = .0833333 WS-DOL-ERN = .49 Working storage: 77 WS-HRS-WRK PIC 9(2)V9(6) COMP. 77 WS-DOL-HR PIC 9(2)V9(2) COMP. 77 WS-DOL-ERN PIC 9V9(2) COMP. The same formula in Excel gives $5.93/hr which is the correct answer. This is only happening when dol-ern is very small. Thanks for any ideas. E.