Floating point and insularity was Re: cobol data format!!! urgent!!!
From: Clark F. Morris, Jr. (cfmtech_at_istar.ca)
Date: 02/05/05
- Next message: Richard: "Re: If you were inventing CoBOL..."
- Previous message: Peter Lacey: "Re: If you were inventing CoBOL..."
- Next in thread: Chuck Stevens: "Re: Floating point and insularity was Re: cobol data format!!! urgent!!!"
- Reply: Chuck Stevens: "Re: Floating point and insularity was Re: cobol data format!!! urgent!!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 04 Feb 2005 22:54:11 -0400
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...
>
>>On Thu, 26 Aug 2004 17:53:40 -0700, "Chuck Stevens"
>><charles.stevens@unisys.com> wrote:
>>
>>
>>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>>news:1j1si05tv3jdi13t2j0lchj0e9u3kkjg0e@4ax.com...
>>>
>>>
>>>>Like most standard committees, the 10967 folk take the attitude 'if
>>>>you don't do it our way, you're on your own.' Why should they support
>>>>the competition in IEC 559?
>>>
>>>And what would you expect "if you do <x> the expected results are <y>" to
>>>imply if you refuse to follow the constraints of <x>? Perhaps I have
>>>misunderstood what "conformance to a standard" means.
>>
>>It would be nice if they'd allocated two bits and defined four values
>>as 10967, 559, native and unknown. They had the arrogance to name the
>>indicator ISO, which implies 559 is not an ISO standard.
>
>
> It's not. It's an *IEC* standard.
>
>
>>>>>What *one* format of high-precision floating-point do you believe is
>>>>>appropriate for *every* existing machine, producing identical results
>>>
>>>across
>>>
>>>>>all platforms?
>>
>>... intermediate conversation elided for brevity ...
>
>
>>... I meant IEEE generically. Its 32-bit and
>>64-bit versions are in current hardware; extended formats generally
>>are not.
>
>
> 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?
>
>
>>I didn't say they did; I said the ISO C++ standard has a long double
>>AND claims to be compliant with 10967. The C++ standard committee
>>found 10967 extended format adequate. This document explicitly says
>>"extended" for long double, not for the others.
>
>
> 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.
>
>
>
>>>And each went their own way. That's precisely my point.
>>
>>Machines designed after 1985 went with IEEE. They did not go their own
>>way.
>
>
> 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?
>
>
>>It was offered as an example of 128-bit. If I'd read it more
>>carefully, I wouldn't have used it.
>
>
> You're responsible for that choice!
>
>
>>With the base types that were defined in 1985.
>
>
> 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.
>
>
>
>>I dispute that floating-point formats are typically defined for the
>>individual platform. They haven't been since 1985.
>
>
> 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?
>
>
>>IBM S/390 now has IEEE 754 hardware support.
>
>
> Goody for them. The 32-bit and 64-bit formats are *still* not adequate for
> 31-digit COBOL arithmetic.
>
>
>>All those follow IEEE 754.
>
>
> The other question I have is whether they also follow IEEE 854, and the
> various ISO and IEC standards *already published*.
>
>
>>>Or is it the irrelevance of everything but PC's to the world of COBOL
>
> these days?
>
>>On the Top 500 computer list, 93% are based on Intel, Power, HP, AMD
>>or Alpha. For instance, the Thunder system at Lawrence Livermore
>>delivers 20 teraflops from 4K Intel Itaniums chewing on IEEE 754
>>numbers.
>>
>>Granted, that's not a likely Cobol machine. But high-end servers from
>>Sun and HP costing $2M are candidates, as are millions of mid-range
>>servers.
>>None of these machines are PCs.
>
>
> Are any of them capable of the 32-digit arithmetic that COBOL requires (and
> COBOL requires it because *users* demanded it)?
>
>
>>I didn't site these sources to show a 128-bit implementation; I cited
>>them to show that chip manufacturers are serious about following IEEE
>>754. They don't go their own way. They do not define floating-point
>>formats for each platform.
>
>
> 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
>
>
- Next message: Richard: "Re: If you were inventing CoBOL..."
- Previous message: Peter Lacey: "Re: If you were inventing CoBOL..."
- Next in thread: Chuck Stevens: "Re: Floating point and insularity was Re: cobol data format!!! urgent!!!"
- Reply: Chuck Stevens: "Re: Floating point and insularity was Re: cobol data format!!! urgent!!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
