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

• Previous message: Robert Wagner: "Re: Rounding errors"
• In reply to: Robert Wagner: "Re: cobol data format!!! urgent!!!"
• Next in thread: Robert Wagner: "Re: cobol data format!!! urgent!!!"
• Reply: Robert Wagner: "Re: cobol data format!!! urgent!!!"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 26 Aug 2004 17:53:40 -0700

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

> >What *one* format of high-precision floating-point do you believe is
> >appropriate for *every* existing machine, producing identical results
across
> >all platforms?
>
> IEEE 754. That's not only my belief, that's reality. It's in most
> Intel, Motorola, Power PC, Sun and HP CPUs. It's even in S/390. See
> below.

IEEE 754 in its current form does *not* specify a *single* format of
*high-precision* floating-point. It specifies a whole range of them, all
equally valid. That's my point.

> >"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?
>
> I'd say decimal. Cobol people 'know' binary floating-point is
> inappropriate for bidness use because it cannot represent .01 exactly.

It's still implementation defined. The quotation above is from IEEE 754.

> As far as I know, every C++ implementation has float and double. The
> addition of long double is logical.

What you haven't demonstrated is that every implementation of C++ has a
"long double", or that what is logical as a representation of a "long
double" in one implementation is exactly the same as every other
implementation of a "long double", or whether any of those implementations
actually are identical to either BINARY128 or DECIMAL128 floating-point
formats as proposed in the August 20 draft of IEEE 754. Thus, "the
addition of long double is logical" is similar to "if we had some ham, we
could have some ham and eggs. If we had some eggs."

> PACKED DECIMAL requires bit addressability on platforms that don't
> support it in hardware i.e. all except IBM and Unisys.

Really? "Each implementor specifies the precise effect of the USAGE IS
PACKED-DECIMAL clause upon the alignment and representation of the data item
in the storage of the computer ...".

> Accessing bits doesn't require bit-addressable memory; it requires an
> AND instruction. You already knew that.

I didn't say "accessing bits", I said "bit addressibility", and perhaps I
should have said "nonpreferential bit addressibility", an environment in
which there are no natural boundaries above the bit level. In such an
environment, accessing a 27-bit "word" that begins at bit 37,421 of the
system memory is accomplished using the same number of instructions as
accessing a 32-bit word at bit 32,768.

> Perhaps the standards process is too slow for real-world use. DEC,
> Sun, et al. couldn't afford to sit on their hands for 20 years. They
> reasonably went with the closest standard, or approximation thereof,
> available at the time. If there had been a standard, they would have
> used it.

And each went their own way. That's precisely my point.

> It was legacy design. The VAX 'G' format looked like IEEE but did not
> behave the same.

Your citation as an example of an implementation of an IEEE 754 format, with
all that entails.

> More recent DEC designs, such as Alpha, are compliant.

With a design that wasn't defined as part of IEEE 754 until 12 November
2001?

> >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.
>
> I dispute that. It WAS typical in the mainframe world and elsewhere
> prior to 1985. It wasn't the case in 2002.

You dispute *what*? That the Unisys OS/2200 floating-point format isn't the
same as the IBM System/390 format which isn't the same as the Unisys MCP
format which isn't the same as the 16-bit Intel format which isn't the same
as the Sun format which isn't the same as the 32-bit Intel format which
isn't the same as the 64-bit Intel format? Or is it the irrelevance of
everything but PC's to the world of COBOL these days?

> This document shows how Intel achieved 100% compatibility with the
> IEEE standard, in behavior as well as format.
>
> "Two subsections are dedicated to the floating-point divide,
> remainder, and square root operations, which are implemented in
> software. It is shown how IEEE compliance was achieved using new IA-64
> features such as fused multiply-add operations, predication, and
> multiple status fields for IEEE status flags. Derived integer
> operations (the integer divide and remainder) are also illustrated.
> IA-64 floating-point exceptions and traps are described, including the
> Software Assistance faults and traps that can lead to further
> IEEE-defined exceptions. The software extensions to the hardware
> needed to comply with the IEEE Standard's recommendations in handling
> floating-point exceptions are specified. "
>
> http://developer.intel.com/technology/itj/q41999/articles/art_6.htm

I'm sorry, but their "double-extended" isn't 128-bit (best I can tell, it
might be as high as 84 bits.)

> Here we see AMD doing rigorous compliance testing:
>
> We describe a mechanically verified proof of correctness of the
> floating-point multiplication, division, and square root instructions
> of The AMD K7 microprocessor. The instructions, which are based on
> Goldschmidt's Algorithm, are implemented in hardware and represented
> here by register-transfer level specifications, the primitives of
> which are logical operations on bit vectors. On the other hand, the
> statements of correctness, derived from IEEE Standard 754, are
> arithmetic in nature and considerable more abstract. Therefore, we
> begin by developing a theory of bit vectors and their role in
> floating-point representations and rounding, extending our previous
> work in conection with the K5 FPU. We then present the hardware model
> and a rigorous and detailed proof of its correctness. All of our
> definitions, lemmas, and theorems have been formally encoded in the
> ACL2 logic, and every step in the proof has been mechanically checked
> with the ACL2 prover
>
> http://nitro.xyzdns.net/~russ/david/papers/k7-div-sqrt.html

"Statements of correctness, derived from IEEE 754" is not the same as "fully
compliant with the requirements of IEEE 754".

> Here we see Motorola describing one of its early (1988) chips:
>
> "The DSP96002 is notable for its full hardware support of IEEE-754
> single-precision and single-extended-precision floating-point
> arithmetic, its two complete sets of external 32-bit address and
> 32-bit data buses, and its lack of common on-chip peripherals. "
>
> http://www.bdti.com/procsum/mot96002.htm

Where's the 128-bit floating-point format that would meet the requirements
of COBOL SIDI's?

> Here is an account of floating-point history by William Kahan. I urge
> you to read the whole report. It's a brilliant description of how a
> good standard was developed.

Don't doubt that.

> Anyone who designed new non-compliant hardware after 1985 had rocks in
> his head. It didn't happen. Non-compliant hardware is old design. So
> make an exception for 'native floating-point' to appease mainframes.

The Unisys MCP floating-point formats were in existence a quarter-century
before that. "Native arithmetic" in COBOL is what COBOL has specified since
the first standard; "standard arithmetic" is what's new to COBOL. And the
two current standard basic formats 32-bit and 64-bit binary floating-point
according to IEEE 754 are *inadequate* to the requirements of standard
arithmetic.

> Looking at it positively, most machines have IEEE hardware .. whether
> Cobol uses it or not. Denying it's there makes Cobol look .. old.

The "Brooklyn Bridge" argument?

> The rules will be the same as 64-bit, logically extended to 128. Just
> as 64 is a logical extension of 32.

The gift of prescience is a precious one indeed. I for one don't know what
IEEE is going to do, or, for that matter, what ISO/IEC is going to do; it
must be very gratifying to you that you can state this as a fact! What of
the *decimal* formats?

> Good answer. I think LIA-1/2 is 'too little, too late'. There are 100M
> chips with IEEE cast into silicon.

Think away. COBOL requires implementations allow for 32 digits of precision
in numeric data items for *both* standard *and* native arithmetic, and
requires 32-digit floating-point representations for SIDI's in standard
arithmetic. The current basic 32-bit and 64-bit floating point
representations aren't adequate to that task, and there is no *single*
extended floating-point format for all platforms to implement in a
compatible manner.

    -Chuck Stevens

• Previous message: Robert Wagner: "Re: Rounding errors"
• In reply to: Robert Wagner: "Re: cobol data format!!! urgent!!!"
• Next in thread: Robert Wagner: "Re: cobol data format!!! urgent!!!"
• Reply: Robert Wagner: "Re: cobol data format!!! urgent!!!"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]