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

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 08/25/04

  • Next message: James J. Gavan: "Re: Microfocus Printing in Columns" 
    Date: Wed, 25 Aug 2004 12:15:22 -0700

    "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
    news:m0vmi0p1e99g7sje29tmnt48rie677dlg3@4ax.com...

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

    Aye, there's the rub. "Usually means ..." doesn't work really well in a
    standard, be it ISO 10967 or ISO/IEC 1989!

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

    Who be "we"? COBOL on Unisys MCP systems has had pretty near "the best
    floating-point available" for forty-odd years! ;-)

    What *one* format of high-precision floating-point do you believe is
    appropriate for *every* existing machine, producing identical results across
    all platforms?

    That question hasn't even been answered in COBOL for "single-word" integers!

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

    "The encoding of extended formats is implementation-defined, and thus their
    size in storage." Quadruple precision formats are *basic*, one binary and
    one decimal, and data items in each format occupy 128 bits. That there are
    exactly two instantiations of extended formats that match the quadruple
    precision format (*still described as proposed* in the DRAFT dated last
    Friday for the next revision of ISO 754!) is a red herring. *Which*
    extended format in the *existing* ISO 754 should the COBOL standard have
    insisted was appropriate for all implementations?

    > 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

    >From what I see, this is a panoply of formats, not a single one appropriate
    to all implementations.

    > "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

    And ... Are you prepared to demand that all COBOL vendors support
    bit-addressability and arbitrary word lengths in order to provide for
    "extended double precision" in all formats? Of all vendors around, I'd
    argue that Unisys has more experience with that than anyone else around,
    based on my eighteen years of intimate exposure to the Burroughs Small
    System -- which had bit-addressable memory and for which the microcode
    provided different word lengths (if any word orientation at all) for each
    language! I don't think other vendors would appreciate a demand by the
    COBOL standard for such flexibility!

    > "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

    Ditto. This isn't a *basic* format, it's an *extended* format. It is still
    *proposed* as a *basic* format as of the draft of the next revision for IEEE
    754 *from last Friday*.

    > 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

    And with the exceptions in range cited above, I'm supposed to assume that
    the 32-bit and 64-bit encodings are consistent with the goal of
    unconditionally identical results on *all* platforms? That someone has
    implemented something that looks like, and sometimes works like an IEEE 754
    format doesn't impress me much!

    It does appear that the particular choice for an Extended X-floating type
    does match what is proposed as a basic type in IEEE 754, but it ain't in
    IEEE 754 as a *basic* type yet, it is one among an undefined number of
    possibilities within the set of extended binary floating-point formats.

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

    I believe the *basic* 32-bit and the *basic* 64-bit floating-point encodings
    are inadequate for general COBOL use, both in terms of precision and in
    terms of range. There is not a *single basic* IEEE floating-point format
    that is sufficiently capacious for COBOL. Once one of these standards
    provides a *single basic* format adequate to contain a Standard Intermediate
    Data Item then that format, and the rounding and precision loss rules
    associated with that format, can be *considered* for *standard* COBOL.

    Any vendor is free to provide support for whatever formats he wants, and for
    whatever rules for "native arithmetic" he deems appropriate.

    > 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

    Yes, this was in response to a comment from the national standards body of
    Sweden about the Final Committee Draft, and I agree with the response, which
    represented J4's consensus.

    Your DEC example above amply illustrates my big concern for the 32-bit and
    64-bit encodings: even if the format matches, the *operating environment*
    (regardless of system, hardware, platform, whatever you want to call it) has
    to *operate the same* regardless. This looks like IEEE floating-point
    formats, but the documentation expressly states that it doesn't behave like
    them.

    And as to her concern: floating-point formats are *typically* defined for
    the individual platform, and the 2002 standard COBOL definition allows them
    to be what the platform defines them to be. If the COBOL compiler required
    that IEEE-format floating-point be used, and the Pascal compiler on the same
    platform used native-format floating-point, the two are incompatible. For
    any degree of more-than-snail-like performance, in order to make good use of
    IEEE floating point formats, the particular platform vendor has to provide
    *hardware* support for the format. Not all do, not all wish to do so, not
    all believe that there is sufficient customer demand for this feature.

    I don't believe an ISO standard has yet "blessed" a *single* extended
    X-floating format; my best guess is that the 128-bit decimal and binary
    floating-point formats in the draft will be in the next revision of IEEE
    754, and promulgated into ISO standards from there. Until ISO (or IEEE)
    establishes hard-and-fast rules for rounding and precision loss in
    arithmetic for those *specific* formats, I don't think there's much chance
    of convincing WG4 that this is a worthwhile addition to the standard.

    Once these formats are accepted *as a basic format in an international
    standard*, I see significant merit in the idea of data types corresponding
    to them, and even in the idea of support (in the language, in hardware, and
    in supporting software) for the IEC/IEEE arithmetic rules corresponding to
    the six basic IEEE 754 floating-point formats in a manner similar to, and
    according to the precedent established by, the ARITHMETIC clause of the
    OPTIONS paragraph. But *only* once the 128-bit encodings are ensconced as
    *basic* formats in an ISO or IEC standard.

    Note that another comment from Sweden was "Reference, and use later on,
    LIA-1 (ISO/IEC 10967-1:1994; note, however, annex E of LIA-2). LIA-1 is
    "Language independent arithmetic-integer and floating point arithmetic."
    The J4 response was "Most of the arithmetic specification in FCD 1989
    existed in the previous edition of the COBOL standard and cannot be changed
    incompatibly. WG4 will investigate mapping to LIA-1 in a future standard".

    In this context, since the FCD that was being commented on was that which
    has already led to ISO/IEC 1989:2002, and since WG4 has already indicated to
    J4 what feature content they will accept in the planned 2008 draft, and by
    their direction that feature content doesn't include LIA-1 and LIA-2. So
    far as I can tell, *basic* floating-point formats (as distinct from specific
    or arbitrary selections from among the many possible *extended*
    floating-point formats) sufficient to encompass the requirements of a COBOL
    Standard Intermediate Data Item do not *yet* exist in a *published*
    international standard. "Future standard" in this case means "some version
    of the standard after the one being proposed for publication in 2008", so
    from that I'd think it'd be safe to surmise that LIA-1 and LIA-2 support
    won't show up in an approved version of ISO/IEC 1989 any time soon.

        -Chuck Stevens

  • Next message: James J. Gavan: "Re: Microfocus Printing in Columns"

    Relevant Pages

    • Re: Program templates as Object Classes
      ... on the ISO Date/Time formats proposal. ... provided *precisely* so that a *single standard* numeric format including ... personal focus is on "core COBOL" and extending what's already there. ... In addition, at the WG4 meeting in October, with the support of J4, I ...
      (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)
    • 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!!!
      ... >COBOL, regardless of which compiler you're talking about. ... >COMPUTATIONAL is standard COBOL. ... >to determine how compatible with IEEE 754 they are. ... Floating-point numbers contain a flag specifying whether they follow ...
      (comp.lang.cobol)
    • Re: Computer Statement Usage
      ... Did you MISS the part that said *decimal* floating-point? ... COBOL "ARITHMETIC IS STANDARD" support *may* actually perform well (when/if it ... >>> Assuming intermediates are fixed-point .. ...
      (comp.lang.cobol)