Michael Berkowitz <[log in to unmask]> wrote:

>The 18 digits are as hard as diamond.  There is no sort of correct
>numeric type in Cobol.  2 + 2 = 4, not 3.99999999999999999.  As for
>representation, like at Burger King, have it your way.  You can have the
>digits as full bytes (PIC 9 DISPLAY(IMAGE type Z)), integer format (PIC 9
>COMP(IMAGE type I)) or as nibbles (PIC 9 COMP-3(IMAGE type P)).  All
>formats support from 1 to 18 digits with any number of digits on either
>side of the decimal point.  PIC V9(18) is valid as is PIC 9(18) or anything
>inbetween.  In the Cobol 2000 standard, this will jump to 31 digits.  The
>only time that there is rounding or trunction is doing multiplication or
>division, the field with the least number of decimal digits determines
>decimal accuracy.

Thanks for the info, Mike.  This is quite reassuring for Cobol folks, indeed.



But then, again, we just received this further information from the
developer who began the thread:


I think the problem here is of understanding what 'significance' means.
It doesn't mean significant places of decimals. It means the number of
digits, before or after an arbitrarily long string of zeros relative to
the decimal point, that accuracy will be preserved to.


The EMU requirement is that conversions be accurate to six significant
digits. So if I am converting £2,345,678,901.23 to EMUs at (say) 1.4
EMUs per £, I am allowed 1,675,480,000 as a sufficient answer. Note, six
*digits*, not six *places*.

Now, if I want to convert 1 lira to EMUs at, say, 2800 lira to the EMU,
I must allow for 0.000357143. Again, six significant *digits*, but it
needs 9 *places* of decimals.

Now, this is all nice and easy for 'real' numbers, which just slide the
base up and down, and it lets them off the accuracy hook in the mantissa
as a bonus. But it's a nightmare for 'fixed' COBOL numbers. They let you
specify an implied decimal place, sure, but you can't slide it up and
down at will.

The top end of the range above encompasses the annual turnover of the
largest group of companies using our product at present. Other UK
companies (e.g. BT) are significantly bigger, but don't use our product
:-(.

The bottom end of the range is the smallest amount I can think of in any
currency that we might have to convert to EMUs. The Italians don't have
coins that small any more. However, we get hooked into some surprisingly
small amounts in Purchasing, where (for example) we have to track the
issue and costing of staples in units, when they are bought in 1000s.

Now a single COBOL data field, even providing 18 digits, won't cover
both of the above.

I have thought about having a sliding decimal point, defined in a
separate field, thus using COBOL to fake reals (base and mantissa) in a
rather ugly way. But even then, I'm not sure we could reliably do the
math.....

-----


The plot thickens as the decimal point (implied or not) slides!





 _______________
|               |
|               |
|            r  |  Alfredo                     [log in to unmask]
|          e    |                                  www.adager.com
|        g      |  F. Alfredo Rego               Tel 208 726-9100
|      a        |  Manager, R & D Labs           Fax 208 726-2822
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
|               |
|_______________|