Cobol - Floating point and insularity was Re: cobol data format!!! urgent!!!

Author

Floating point and insularity was Re: cobol data format!!! urgent!!!

Clark F. Morris, Jr.

2005-02-05, 3:55 am

I am top posting and keeping the original long dialog because I want to
keep the history without trying to find appropriate places to
intersperse. My general impression is that we in the computer industry
tend to be very insular. I know that I really don't know that much
about the world outside of COBOL, IBM z series assembler, various 4th
generation languages that run on the z series and JCL. I am fairly
knowledgeable about some of them but admit that I probably am increasing
ignorant of just these areas let alone the wider world. The problem
with this insularity is that there is a lot of re-invention of the wheel
and slightly different and incompatible methods of implementing the same
function for each of the many languages. In regard to floating point,
the main need from a COBOL programmer's point of view is the ability to
share variables with Windowing, graphic, Scientific and Java
environments. I look upon the lack of IEEE floating point in the IBM
enterprise COBOL (something that could be most easily handled by
implementing the 2002 standard and making the floating point usages IEEE
leaving the COMP-1 and COMP-2 usages hex floating point) as an example
of this insularity.

Indeed,
Chuck Stevens wrote:
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:jm8ti01aeo3igm42n2d2ole964csm8k3v7@
4ax.com...
>
>
>
> It's not. It's an *IEC* standard.
>
>
>
>
>
>
> And that brings us back to my point that the 2002 standard requires 31-digit
> precision for all numeric data items that have PICTURE clauses, which makes
> the 32-bit and 64-bit formats unusable for manipulating values at that
> precision level.
>
> And you've already gone on record as being *adamantly* opposed to using
> anything but DISPLAY numeric for any sort of data exportation from or
> importation into COBOL programs on grounds of portability. If 32-bit
> formats are virtually useless *within* the COBOL program, and they're to be
> eschewed as visible elements *from or to* a COBOL program, what does COBOL
> need with them?
>
>
>
>
> What the C++ user community directs the standards committee for C++ to
> incorporate and to treat as adequate in that environment is entirely
> orthogonal to what the COBOL community directs the standards committee for
> COBOL to treat as adequate.
>
> The COBOL community has made it abundantly clear to the standards committee
> that the standard requirement that PICTUREs for numeric items provide for no
> more than 18 digits (ANSI X3.23-1974) was an onerous limitation to them, and
> the 2002 standard provides for 31.
>
>
>
>
>
> Machines designed after 1985 *still* don't have a single basic portable
> floating-point format capable of meeting the needs of the COBOL community.
> And I would have to say there are *plenty* of machines designed after 1985
> that neither went their own way nor went with IEEE. What many of them did
> was provide additional capabilities within a given *architecture*.
>
> I remember the stories of IBM introducing the large-scale 704 system as
> their answer for the *scientific* community, and the large-scale 705 system
> for the *business* community. The 705 was fairly successful, and it went
> through two more generations enhancing capability. When the second
> generation was introduced, the 704/709 architecture lived on in the
> 7040/7090, but IBM introduced the entirely-incompatible 7070 as the
> replacement for the 705. Existing 705 customers stayed away in droves,
> forcing IBM to rush the 7080 (which had 705-compatibility switches on its
> console) to market in record time.
>
> I personally think it's a Really Bad Idea for a manufacturer to turn its
> back on an existing customer base or to force a user to abandon an existing
> library of his programs with which he is otherwise quite satisfied.
>
> While many (and I daresay not all!) new *architectures* may have
> incorporated hardware support for 32-bit and 64-bit basic floating-point
> formats, if they're not suitable for internal use within COBOL, there's not
> a whole lot of incentive for the *COBOL* standard to "bless" them as an
> attractive new feature for that language! What's the attraction?
>
>
>
>
> You're responsible for that choice!
>
>
>
>
> The term "base type" does not appear in IEEE 754. The term "base" is used
> in IEEE 754 only to describe the number base used for the representation.
> The 128-bit format is not a *basic format* in 1985, it's a possibility from
> among the myriad possible *extended formats*. IEEE 754 doesn't
> characterize the 128-bit format as a "base type", and I'd say goes to rather
> significant lengths to indicate otherwise, both for the general and the
> specific cases.
>
>
>
>
>
> Are you *truly* insisting that the floating-point formats designed decades
> ago for the Burroughs Large System, the IBM 360, the Univac 1108, and other
> platforms whose architectures continue to attract new customers to this day
> *ceased to exist as defined formats* in 1985?
>
>
>
>
> Goody for them. The 32-bit and 64-bit formats are *still* not adequate for
> 31-digit COBOL arithmetic.
>
>
>
>
> The other question I have is whether they also follow IEEE 854, and the
> various ISO and IEC standards *already published*.
>
>
>
> these days?
>
>
>
> Are any of them capable of the 32-digit arithmetic that COBOL requires (and
> COBOL requires it because *users* demanded it)?
>
>
>
>
> Being serious about IEEE 754 isn't necessarily the same as being serious
> about meeting the needs of the large financial institution or the large
> manufacturer. Or of the average COBOL user.
>
> 32-bit and 64-bit basic binary floating-point formats from IEEE 754 might be
> a "nice touch" for standard COBOL, but doesn't add functionality as far as
> I'm concerned. The implementor of COBOL for a given platform is *today*
> free to use these formats for USAGE FLOAT-SHORT, FLOAT-LONG and/or
> FLOAT-EXTENDED -- or to *not* use them for those USAGEs -- *whether or not
> the target platform provides hardware support for these formats*.
>
> As for BINARY-CHAR, BINARY-SHORT, BINARY-LONG and BINARY-DOUBLE, what each
> of these is understood to mean in a given environment in COBOL or otherwise
> is frequently defined in terms of the word length of the individual
> *platform*. This means that what is BINARY-LONG on one machine may be
> BINARY-SHORT on another. And what I read of C++, the same is true there.
>
> The only formal movement I've seen toward the adoption of IEEE-style
> floating-point formats *in language standards* is in the current draft for
> the next FORTRAN standard.
>
> Now that a single 128-bit binary floating-point format is *on its way* to
> becoming formally standardized, I personally would think adding support for
> these formats *as a syntactic addition to* the language would be worthwhile,
> and will probably end up pursuing it for a future standard.
>
> But as it is, any implementor on a platform is free to define the three
> standard floating-point formats provided by the language as defining items
> in IEEE formats -- or not -- as they see fit or as their users demand. They
> are also free to provide syntax in the language describing the three IEEE
> formats in implementor-defined extensions -- or not -- as they see fit or
> as their users demand.
>
> As to standardization in other languages, I see the following in an on-line
> C++ reference:
>
> <<The size and range of any data type is compiler and architecture
> dependent. The "cfloat" (or "float.h") header file often defines minimum and
> maximum values for the various data types. You can use the sizeof operator
> to determine the size of any data type, in bytes. However, many
> architectures implement data types of a standard size. ints and floats are
> often 32-bit, chars 8-bit, and doubles are usually 64-bit. bools are often
> implemented as 8-bit data types.>>
>
> "Often" is not "always", even in standard C++, as I see it. In a
> (hypothetical) machine with addressibility at 64-bit boundaries, does a
> 32-bit int (or BINARY-SHORT) really make all that much sense? The extra
> cost that might be incurred by arithmetic involving a BINARY-LONG instead of
> a BINARY-SHORT might actually be offset by the cost of retrieving the
> half-word item! I have seen the Intel architecture go from 16 to 32 to 64
> bits. How long will it be before the "native word length" for commodity
> hardware becomes 128 bits, and thus the logical format for a "long
> double-precision item" occupies 512 bits?
>
> -Chuck Stevens
>
>

Chuck Stevens

2005-02-14, 3:55 pm

The article to which Clark Morris is responding is from a while back.

IEEE is in the process of developing a new floating-point arithmetic
standard to replace the current IEEE 754. The current draft of this
proposal can be found by navigating through http://754r.ucbtest.org/ .
Rumor on the street is that IEEE will approve this proposal sometime this
year.

As requested by ISO/IEC JTC1/SC22/WG4 at the meeting in The Hague last
October, a proposal has been written to incorporate Decimal128 and Binary128
floating-point formats from IEEE 754r as both explicitly-defined USAGEs (the
current names are FLOAT-DECIMAL-34 and FLOAT-BINARY-34, the "34"
representing the exact -- in the case of decimal -- and approximate -- in
the case of binary -- number of decimal digits of precision available in
them) and as the bases for new forms of arithmetic alongside the "native"
and "standard" specified in the 2002 draft.

The author's primary intent in developing this proposal was to place
responsibility for both the precision and the rounding rules for arithmetic
and other operations into a language-independent, platform-independent
format that itself was accepted as an international standard. That is to
say, to *eliminate* the very insularity which you decry.

A secondary purpose was to expand the sorts of rounding that a user may
specify, both in intermediate results (where truncation currently applies
unconditionally in standard arithmetic) and in final ROUNDED clause (where
the user currently may only choose between "truncation" and "round to
nearest, with ties away from zero"). In the case of intermediate results,
"banker's rounding" and "exception on inexact results" have been added; in
the case of the final ROUNDED clause, there are now a total of eight
modes -- all of the mandatory IEEE 754r ones, plus a few from the Java
BigDecimal class.

This proposal was accepted at the most recent meeting of INCITS/J4 last w

and will be in the next version of the Working Draft for a future COBOL
standard. The approved proposal itself should show up in the list of J4
documents at http://www.cobolportal.com/j4/ Real Soon Now as J4 document
05-0047.

In the meantime, I believe Decimal128 is of sufficient precision so as to
allow its use as a format underlying 2002 COBOL's Standard Arithmetic (as
well as the proposed Standard-Decimal arithmetic) for any implementor who
wished to make use of it.

-Chuck Stevens

"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:36iqueF5214p1U1@uni-berlin.de...
> I am top posting and keeping the original long dialog because I want to
> keep the history without trying to find appropriate places to
> intersperse. My general impression is that we in the computer industry
> tend to be very insular. I know that I really don't know that much
> about the world outside of COBOL, IBM z series assembler, various 4th
> generation languages that run on the z series and JCL. I am fairly
> knowledgeable about some of them but admit that I probably am increasing
> ignorant of just these areas let alone the wider world. The problem
> with this insularity is that there is a lot of re-invention of the wheel
> and slightly different and incompatible methods of implementing the same
> function for each of the many languages. In regard to floating point,
> the main need from a COBOL programmer's point of view is the ability to
> share variables with Windowing, graphic, Scientific and Java
> environments. I look upon the lack of IEEE floating point in the IBM
> enterprise COBOL (something that could be most easily handled by
> implementing the 2002 standard and making the floating point usages IEEE
> leaving the COMP-1 and COMP-2 usages hex floating point) as an example
> of this insularity.
>
> Indeed,
> Chuck Stevens wrote:
to[color=darkred]
31-digit[color=darkred]
makes[color=darkred]
be[color=darkred]
COBOL[color=darkred]
for[color=darkred]
committee[color=darkred]
for no[color=darkred]
and[color=darkred]
community.[color=darkred]
1985[color=darkred]
did[color=darkred]
system[color=darkred]
went[color=darkred]
its[color=darkred]
existing[color=darkred]
not[color=darkred]
used[color=darkred]
representation.[color=darkred]
from[color=darkred]
rather[color=darkred]
decades[color=darkred]
other[color=darkred]
day[color=darkred]
for[color=darkred]
(and[color=darkred]
might be[color=darkred]
as[color=darkred]
not[color=darkred]
each[color=darkred]
otherwise[color=darkred]
there.[color=darkred]
for[color=darkred]
to[color=darkred]
for[color=darkred]
worthwhile,[color=darkred]
items[color=darkred]
They[color=darkred]
IEEE[color=darkred]
or[color=darkred]
on-line[color=darkred]
and[color=darkred]
operator[color=darkred]
are[color=darkred]
often[color=darkred]
extra[color=darkred]
instead of[color=darkred]
64[color=darkred]
>
>
>
>
>
>

Clark F. Morris, Jr.

2005-02-16, 3:55 pm

I appreciate this message from Chuck. I urge that the COBOL community
follow this and urge their vendors to support the new standard when it
becomes available. The hardware support also should be requested where
appropriate. As I stated in my earlier post, COBOL does not exist in a
vacuum. There is the need for COBOL to exchange data with routines
written in C, C++, Java and a host of other languages. In order to do
this efficiently and effectively, the compiler must recognize the basic
data types and not require a translation layer (something that I believe
IBM does in their COBOL to JAVA parameter passing for floating point hex
to IEEE). If passed, this proposal means that other languages will be
able to interoperate with COBOL better (or do what COBOL does).
Integration of this proposal in COBOL will enhance its business handling
capability and possibly eliminate the need for peculiar routines.
Because it deals with basic data types and operations, if passed it
probably should have as high a priority for X3J4 as XML does. Further,
the various user groups should press their vendors for incorporation.
We don't need a tower of Babel of inconsistent implementations. Again
much thanks to Chuck. I will be passing this on to the ibm mainframe
listserv.

Chuck Stevens wrote:
[color=darkred]
> The article to which Clark Morris is responding is from a while back.
>
> IEEE is in the process of developing a new floating-point arithmetic
> standard to replace the current IEEE 754. The current draft of this
> proposal can be found by navigating through http://754r.ucbtest.org/ .
> Rumor on the street is that IEEE will approve this proposal sometime this
> year.
>
> As requested by ISO/IEC JTC1/SC22/WG4 at the meeting in The Hague last
> October, a proposal has been written to incorporate Decimal128 and Binary128
> floating-point formats from IEEE 754r as both explicitly-defined USAGEs (the
> current names are FLOAT-DECIMAL-34 and FLOAT-BINARY-34, the "34"
> representing the exact -- in the case of decimal -- and approximate -- in
> the case of binary -- number of decimal digits of precision available in
> them) and as the bases for new forms of arithmetic alongside the "native"
> and "standard" specified in the 2002 draft.
>
> The author's primary intent in developing this proposal was to place
> responsibility for both the precision and the rounding rules for arithmetic
> and other operations into a language-independent, platform-independent
> format that itself was accepted as an international standard. That is to
> say, to *eliminate* the very insularity which you decry.
>
> A secondary purpose was to expand the sorts of rounding that a user may
> specify, both in intermediate results (where truncation currently applies
> unconditionally in standard arithmetic) and in final ROUNDED clause (where
> the user currently may only choose between "truncation" and "round to
> nearest, with ties away from zero"). In the case of intermediate results,
> "banker's rounding" and "exception on inexact results" have been added; in
> the case of the final ROUNDED clause, there are now a total of eight
> modes -- all of the mandatory IEEE 754r ones, plus a few from the Java
> BigDecimal class.
>
> This proposal was accepted at the most recent meeting of INCITS/J4 last w

> and will be in the next version of the Working Draft for a future COBOL
> standard. The approved proposal itself should show up in the list of J4
> documents at http://www.cobolportal.com/j4/ Real Soon Now as J4 document
> 05-0047.
>
> In the meantime, I believe Decimal128 is of sufficient precision so as to
> allow its use as a format underlying 2002 COBOL's Standard Arithmetic (as
> well as the proposed Standard-Decimal arithmetic) for any implementor who
> wished to make use of it.
>
> -Chuck Stevens
>
> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
> news:36iqueF5214p1U1@uni-berlin.de...
>
>
> to
>
>
> 31-digit
>
>
> makes
>
>
> be
>
>
> COBOL
>
>
> for
>
>
> committee
>
>
> for no
>
>
> and
>
>
> community.
>
>
> 1985
>
>
> did
>
>
> system
>
>
> went
>
>
> its
>
>
> existing
>
>
> not
>
>
> used
>
>
> representation.
>
>
> from
>
>
> rather
>
>
> decades
>
>
> other
>
>
> day
>
>
> for
>
>
> (and
>
>
> might be
>
>
> as
>
>
> not
>
>
> each
>
>
> otherwise
>
>
> there.
>
>
> for
>
>
> to
>
>
> for
>
>
> worthwhile,
>
>
> items
>
>
> They
>
>
> IEEE
>
>
> or
>
>
> on-line
>
>
> and
>
>
> operator
>
>
> are
>
>
> often
>
>
> extra
>
>
> instead of
>
>
> 64
>

Clark F. Morris, Jr.

2005-02-20, 8:55 pm

Sponsored Links