F. Alfredo Rego ([log in to unmask]) wrote:
: ...
: 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 =A32,345,678,901.23 to EMUs at (say) 1.4
: EMUs per =A3, I am allowed 1,675,480,000 as a sufficient answer. Note, six
: *digits*, not six *places*.

: ...

: 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.....

: ...

Business BASIC/iX DECIMAL and SHORT DECIMAL data types provide floating
point decimal arithmetic.  These types are represented internally
with an exponent and mantissa.  The ranges of values supported are:

SHORT DECIMAL: [-9.99999E63, -9.99999E-63], 0, [9.99999E-63, 9.99999E63]
               Precision is exact to 6 digits.

DECIMAL: [-9.99999999999E511, -1.00000000000E-511], 0,
         [1.00000000000E-511, 9.99999999999E511]
               Precision is exact to 12 digits.

If you are using a language that does not support decimal arithmetic
and you need exact results, you may be able to use integers (~9 digits)
or floating point reals (~15 digits for double, I forget how many for
long double) to do the arithmetic.  You would have to take care of
adjusting the decimal points yourself, though.

Sue Meloy