RE: Questions on data transfer and non-arithmetic handling rules
COBOL doesn't (yet) claim conformance to 754, but when/if it does, I believe
that all the "conversion" routines could/would be available via the
"COMPUTE" statement of intrinsic functions similar to those existing today.
today COBOL allows for
Compute OneNumericTyupe = AnotherNumericType
where the sending item (right side of the equal sign) and the receiving item
(left side of the = sign) can be the same or a different numeric "USAGE".
In addition, COBOL also has (today) several functions that take "strings" of
information and convert them to numeric data to be stored in any type of
numeric field. For example,
Compute NumField = NumVal (1,223.44)
Compute NumField = NumVal-F (+1.234E-76)
(The arguments to the "built-in" functions (NumVal and NumVal-F - and there
are some others) can be "literal strings" or data items containing such
string. There is not (today) a
function that would take data in the format of a hex-string, but that could
easily be added (and would, in COBOL consideration be a "numeric" context).
the difference COBOL has is arithmetic statements versus data transfer
Move Sending-Item to Receiving-Item
is NOT guaranteed to get the same results as the comparable
Compute receiving-item = sending-item
The first (historically) follows the rules for data transfer while the
second follows the rules for arithmetic. When/if COBOL claims to be
754-conforming, I would certainly EXPECT the COMPUTE statement to work as
defined in 754. The question (that Chuck was getting at) was
*IF* COBOL provides the functionality via the COMPUTE statement, must the
"similar but not identical" MOVE statement also work in the same way.
I read your (Stephen's) reply to mean that as long as the functionality is
provide by one means, then 754 says nothing about how "other" similar
features work. If the programming language does not (normally) require them
to always work the same, then 754 would not do this for any of the formats
defined in the 754 Standard. Again, as I originally said, I certainly do
not think that 754 prohibits two similar functions in a programming language
from BOTH working as defined in 754. However, it does not require it either
- as long as ONE provided feature does meet the 754 specification.
From: Stephen Canon [mailto:scanon@xxxxxxxxx]
Sent: Saturday, April 30, 2011 5:13 PM
To: William M Klein
Cc: IEEE 754; Charles Stevens
Subject: Re: Questions on data transfer and non-arithmetic handling rules
I think that it's important to begin by noting the language in the very
first sentence of Clause 5:
"All conforming implementations of this standard shall provide the
operations listed in this clause for all supported arithmetic formats,
except as stated below."
The important thing to note is that Clause 5 defines a set of operations
that must be provided by a conforming language implementation. It does not
specify how those operations are bound in a conforming language, nor does it
proscribe a language providing additional operations on floating-point data
that do not adhere to any clause in the 754 document.
Thus, if a language wants to claim 754 support, it must (among many other
- Provide means to convert all supported formats to and from all
supported integer formats (5.4.1)
- Provide means to convert all supported formats to and from decimal
- Provide means to convert all supported binary formats to and from
hexadecimal strings (5.4.3)
A language may provide additional conversions that do not follow the
IEEE-754 rules, so long as the conversions defined in 5.4 are also
available. A language may also provide additional arithmetic operations
that are not defined in IEEE-754, or anything else, so long as there are
also bindings that allow a programmer to access the functionality specified
in clause 5 (and the rest of the normative standard).
That said, there may be an impedance mismatch with regard to how the term
"arithmetic" is used in IEEE-754 and in the COBOL community. IEEE-754
specifies a great many operations besides those in the "Arithmetic
operations" clause. These are no less a part of the standard, nor is there
presence in a conforming implementation optional. For example, in C,
convertFromHexCharacter( ) for the double format might be bound to strtod,
and could be used as follows:
double x = strtod( someUserSpecifiedString, NULL, 16 );
Does any "arithmetic" occur in this expression? To my mind, and according to
the naming of the clause 5 operations, it does not. Does this match with
your (or COBOL's) notion of an "arithmetic context"? Maybe you consider
expressions like this an "arithmetic context"; if not, I would argue that
your statement "this Standard says NOTHING about the handling of such items
outside of arithmetic contexts" is incorrect, because the standard does
require that the defined operations be available in such a context.
On Apr 30, 2011, at 2:39 PM, William M Klein wrote:
to the list (and Chuck who already knows this),
As one of (if not the only one) from the COBOL group who is in the
"others differ " group, I read the initial "scope" and "purpose" clauses of
754 to mean that this Standard is intended for "arithmetic" and the primary
purpose of the "conversion" sections is for converting from one numeric
format to another when used in/for arithmetic statements, operations, or
functions (and for comparisons involving numbers in an arithmetic context).
The title of the Standard,
"IEEE Standard for Floating-Point Arithmetic"
is something that I have always believed means what it says and says what
it means, i.e. that this standard deals with the handling of data items (as
we call them in COBOL) that are defined as one of the formats in this
Standard WHEN it is used in or for arithmetic. If a programming language
support NON arithmetic functionality for numeric items, then this is NOT the
Standard that says how to do this. Obviously, in many (probably most) cases
where there are "similar" functions for the same types of data items one of
which is arithmetic and one that is not, there is nothing in 754 that says
that they cannot (much less should not) get the same results. It is just
that (as I understand it) this Standard says NOTHING about the handling of
such items outside of arithmetic contexts.
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx] On Behalf Of Charles
Sent: Saturday, April 30, 2011 3:27 PM
To: IEEE 754
Subject: Questions on data transfer and non-arithmetic handling rules
1) I do not find any rule offhand in IEEE Std 754-2008 Clause 5.4.2 or
elsewhere that says what happens when the "source" item is exactly the same
format (and encoding) as the "sink" item. My personal assumption is that
this would be a "bit-for-bit" transfer, with no reformatting at all, and
that's what the COBOL rules specify.
QUESTION: Is there a rule that specifies this?
2a) COBOL has two ways of handling data transfer. One of these is under
arithmetic (e.g., COMPUTE B = A), the other is MOVE (MOVE A TO B). The
results are most often the same, but edge-case handling differs. This leads
2b) I note that 3.1.2, Conformance, requires that a conforming
(platform) implementation provides everything in Clause 5, Operations. I
note also that 5.4.2, Conversion operations for floating-point formats and
decimal character sequences, is a subclause under 5,4, formatOf
geneal-computational operations, but is NOT a subclause of 5.4.1, Arithmetic
operations, but falls under a more "universal" classification that also
applies elsewhere if full conformance is to be achieved.
QUESTION: For full conformance to IEEE Std 754-2008, should the
provisions of 5.4.2 and 5.5 be taken to apply "universally", even in cases
in which arithmetic is not involved, in which case any other behavior or
results would be considered "nonconforming", as is indicated by their
placement, or is an environment that specifies behavior different from these
rules for the same operands for non-arithmetic manipulation nevertheless
"conforming"? My opinion is the former, others differ.