Re: cobol data format!!! urgent!!!

From: Robert Wagner (robert_at_wagner.net.yourmammaharvests)
Date: 08/25/04 

Date: Tue, 24 Aug 2004 23:14:19 GMT

On Tue, 24 Aug 2004 09:43:12 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:7ugmi0p0h3r77ukbgki9i08k4k3ioe6pbu@4ax.com...
>
>> Comp-1 means IEEE in many Cobol compilers,
>
> ... in which it darned well better be marked as an extension to standard
>COBOL, regardless of which compiler you're talking about.
>
>COMPUTATIONAL is standard COBOL.
>
>COMPUTATIONAL-1, COMPUTATIONAL-WHATSIS and COMPUTATIONAL-ANYTHING-ELSE mean
>*exactly* and *only* what the particular compiler vendor on the particular
>platform decides they mean, whatever that might be, and regardless of what
>any other vendor on the same or any other platform decides they mean.

When the vendor says it complies with IEEE 754, users refer to that
standard for a definition. Granted it's not Cobol, but it's not
vendor-defined either.

>Is there any COBOL implementation anywhere in which COMP-1 *might* mean
>anything else? How about COMP-2? I know of some ...

You've kindly described here their meaning in Unisys.

>> "IEEE Binary Floating-Point is an industry-standard architecture.
>
>To a point. I haven't obtained a copy of IEC 559:1989 or ISO/IEC 10967:1994
>to determine how compatible with IEEE 754 they are.

IEC 559 is identical. IEC 10967:1994 added integers. Its
floating-point is close but not identical. Differences are in flags
and handling extreme values such as zero and infinity. The 2001 update
added numerical functions.

Floating-point numbers contain a flag specifying whether they follow
10967 or 'other', which usually means 754/559.

>As it stands now, implementors are free to implement one or more of the
>USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
>with IEEE Floating-Point representations, *if they so choose*, but USAGEs
>for the floating-point representations described in IEEE 754 are *not* in
>standard COBOL (of any vintage).

In the 20 years since IEEE 754 was adopted, the computer industry
boomed. Because Cobol offered no floating-point, we used the best
standard available.

>Note also that the 32-bit and 64-bit IEEE representations are insufficiently
>precise or capacious for the purposes of describing a COBOL intermediate
>result, and were thus expressly ruled out as a possible format for the COBOL
>Standard Intermediate Data Item (SIDI) as described in ISO/IEC 1989:2002. .
>
>While the 128-bit quadruple-precision IEEE format that *has been proposed*
>for the next revision of IEEE 754 is better, and might be shown to meet the
>requirements of the COBOL Standard Intermediate Data Item, this format is
>not yet *approved* as part of the IEEE standard.

These four sources say it has been in the standard since 1985. The
last two made machines and/or compilers that used it.

IEC 10967 inherited Extended (below) from the earlier standards. Look
at ISO/IEC 14882, the C++ standard approved in 1998. It includes a
'long double' type and it explicitly cites compliance with IEC 10967.
http://www.kuzbass.ru/docs/isocpp/lib-support.html#lib.support.types

"When comparing the format parameters of "extended double-precision"
in IEEE-754's Table 1 and those of the so-called
"quadruple-precision", one finds that the "quadruple-precision" format
is simply a specific instance of the "extended double-precision"
format. Similarly, one will note that "double-precision" is a specific
instance of "extended single-precision"."
http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html

"The standard defines the encoding for the quadruple-precision
floating-point data type "quadruple" (128 bits or 16 bytes). The
encoding used is designed to be a simple analog of of the encoding
used for single and double-precision floating-point numbers using one
form of IEEE double extended precision. The standard encodes the
following three fields, which describe the quadruple-precision
floating-point number: "
[Sun manual]
http://asg.web.cmu.edu/rfc/rfc1832.html

Language elements that support the various extended range and ex-
         tended precision floating-point architectural features:

 - 32-bit IEEE S_floating data type, with an 8-bit exponent and
23-bit mantissa, which provides a range of 1.17549435E-38 (normal-
 ized) to 3.40282347E38 (the IEEE denormalized limit is 1.40129846E-
45) and a precision of typically 7 decimal digits

 - 64-bit IEEE T_floating data type, with an 11-bit exponent and
 53-bit mantissa, which provides a range of 2.2250738585072013D-
 308 (normalized) to 1.7976931348623158D308 (the IEEE denormal-
  ized limit is 4.94065645841246544D-324) and a precision of typ-
  ically 15 decimal digits

 - 128-bit IEEE extended X_floating data type, with a 15-bit ex-
 ponent and a 113-bit mantissa, which provides a range of approx-
 imately 6.48Q-4966 to 1.18Q4932 and a precision of typically 33
 decimal digits
[DEC manual]
http://www.iac.tut.fi/usr/local/doc/Fortran-90/Version-2.0/f9a200_spd.txt

See also this bibliography. Search for extended.
http://www.cs.berkeley.edu/~dbindel/class/cs279/dsb-bib.pdf

>Note also that so far as I know IEEE 754 is an *American* standard, not an
>ISO-approved one, and that presents practical and diplomatic problems for
>its citation within an *international* standard, particularly if IEC
>559:1989 and ISO/IEC 10967:1994 (which *are* indisputably referenceable in
>another ISO standard) differ from it in any significant way.

That's a problem. It appears that IEC 559 will be replaced by IEC
10967, which has small differences -- not in number representation but
in administrative details.

I cannot find one single compiler, any language, claiming to be
10967-compliant. Yet J4 cannot give us IEEE floating-point because
10967 exists?

>As it stands now, implementors are free to implement one or more of the
>USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
>with IEEE Floating-Point representations, *if they so choose*, but USAGEs
>for the floating-point representations described in IEEE 754 are *not* in
>standard COBOL (of any vintage).

This response from Ann Bennett, only two years ago, rejects the idea
of using EITHER standard in Cobol 2002.

"1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
floating point).

Response: A floating point data type was added in FCD 1989 to
provide access to hardware floating point, which is not universally
IEEE 754. A primary requirement addressed by FCD 1989 is interaction
with other programming languages. A mandated IEEE 754 implementation
would not meet that requirement. "

http://www.cobolportal.com/j4/files/02-0060.doc

Relevant Pages

  • Floating point and insularity was Re: cobol data format!!! urgent!!!
    ... the main need from a COBOL programmer's point of view is the ability to ... I look upon the lack of IEEE floating point in the IBM ... implementing the 2002 standard and making the floating point usages IEEE ... >>formats for each platform. ...
    (comp.lang.cobol)
  • Re: cobol data format!!! urgent!!!
    ... misunderstood what "conformance to a standard" means. ... Cobol people 'know' binary floating-point is ... The quotation above is from IEEE 754. ... same as the IBM System/390 format which isn't the same as the Unisys MCP ...
    (comp.lang.cobol)
  • Re: cobol data format!!! urgent!!!
    ... Like most standard committees, the 10967 folk take the attitude 'if ... support it in hardware i.e. all except IBM and Unisys. ... A mandated IEEE 754 implementation ... "Two subsections are dedicated to the floating-point divide, ...
    (comp.lang.cobol)
  • Re: cobol data format!!! urgent!!!
    ... standard, be it ISO 10967 or ISO/IEC 1989! ... Because Cobol offered no floating-point, ... "The encoding of extended formats is implementation-defined, ...
    (comp.lang.cobol)
  • Re: cobol data format!!! urgent!!!
    ... which implies 559 is not an ISO standard. ... importation into COBOL programs on grounds of portability. ... formats are virtually useless *within* the COBOL program, ... that neither went their own way nor went with IEEE. ...
    (comp.lang.cobol)