Re: Next generation COBOL?


"Steve Richfie1d" <Steve@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3un649F11a8q3U1@xxxxxxxxxxxxxxxxx

> (Note here the indefinite sign, which is part of several proposals
> (including mine) for better computer arithmetic than IEEE-754 floating
> point.

I would have to say that, in both my experience and my observation, *in the
business environment* it is hasn't proved sufficiently useful to distinguish
between a value that has an indefinite sign and a value that has a positive
sign. In that environment, what is interesting is whether the value is
negative or not negative in that regard. If indefiniteness is of interest,
it hasn't *yet* proved interesting enough to warrant "operating environment"
support for it by any vendor.

> MOST computations made by present floating point hardware now produce
> WRONG results! For example, 1.0/3.0 = 0.33 (observing significance), and
> NOT 0.33333333 as computers now universally claim.

That depends on where you place "significance". The Standard Arithmetic
rules in the current COBOL standard indicate that for "COMPUTE X = Y / Z."
the operands Y and Z are converted to decimal *floating-point* values with a
32-decimal-digit mantissa and a three-digit decimal exponent representing
the power of ten, the arithmetic is performed in that form, the result
truncated and normalized in that form, and then truncated (absent a ROUNDED
clause) to reflect the description of the destination. Thus, 1.0 *in COBOL*
is taken to be 1.0000000000000000000000000000000E000, 3.0 is taken to be
3.0000000000000000000000000000000E000, and the quotient in the above
expression is 3.3333333333333333333333333333333E-001. It is only in the
final determination of how that quotient fits in the destination that it
gets truncated, and no matter how many fractional digits that destination
contains they all contain 3.

That may not be the way *mathematicians* want it, but it is the way
*accountants* seem to want it.

IEEE 754 is in the process of revision, and if it gets published in its
current form it will include industry-standard, platform-independent,
environment-independent *decimal* floating-point formats for 32-bit (7 digit
mantissa, +-95 range exponent), 64-bit (16 digit mantissa, +-385 range
exponent), and 128-bit (34 digit mantissa, +-6143 range exponent) encodings.
The COBOL standard being drafted for anticipated publication in 2008 allows
arithmetic in Decimal128 form as described in this draft revision to IEEE
754, and also allows users to describe data items in that form.

I personally both hope and expect that, presuming COBOL survives, IEEE 754r
Decimal128 format will ultimately become The Way arithmetic is done in
COBOL, replacing the "whatever the individual implementor does" approach
associated with 2002 Native Arithmetic (all that was available before the
2002 standard), as well as the "abstract floating-point decimal concept"
approach represented by 2002 Standard Arithmetic.

If you're interested in the current thoughts of the IEEE 754r drafting
committee, see http://754r.ucbtest.org/ .

-Chuck Stevens


.

Relevant Pages

  • Re: Floating point and insularity was Re: cobol data format!!! urgent!!!
    ... I urge that the COBOL community ... IBM does in their COBOL to JAVA parameter passing for floating point hex ... > IEEE is in the process of developing a new floating-point arithmetic ... > standard to replace the current IEEE 754. ...
    (comp.lang.cobol)
  • Re: Floating point and insularity was Re: cobol data format!!! urgent!!!
    ... IEEE is in the process of developing a new floating-point arithmetic ... and "standard" specified in the 2002 draft. ... and will be in the next version of the Working Draft for a future COBOL ... I look upon the lack of IEEE floating point in the IBM ...
    (comp.lang.cobol)
  • Re: Free Floating Point VHDL Library
    ... as a wrapper around the core floating point elements currently in ... and floating point ... code to synthesize. ... The VHDL-93 versions of the packages had the IEEE copyright removed from ...
    (comp.lang.vhdl)
  • Re: Win32Forth & negative zero
    ... or the IEEE? ... Theoretically RNE introduces less bias. ... As for floating point in software, ... In the main float wordset "round to nearest" would be ...
    (comp.lang.forth)
  • Re: replacing SAS for SMF reports?
    ... which is a decimal floating point ... These classes are pure Java ... Enterprise Cobol Compiler and generate Java classes which use the above ... Java does not have Decimal Floating Point yet, ...
    (bit.listserv.ibm-main)