Response to an Entry in the 8/18/2005 Minutes

["Stevens, Charles C" <Charles.Stevens@xxxxxxxxxx>]

Perhaps I am reading more into this digest of the conversations at yesterday's 
meetings than is actually there, but there are several points in the synopsis 
of Prof. Kahan's comments to which I felt it appropriate to respond "on the 
record":   

<<At 4:45 Prof Kahan summarized that existing information provides us with no 
evidence for a market for fast & efficient decimal floating-point in hardware.  
He concludes in the absence of such evidence that we, as a standards body, 
should standardize the arithmetic but not the formats.>>  

I am having some trouble following the logic flow from the premise to the 
conclusion; perhaps there are some steps left out in this description.   

The primary architecture with which I deal -- the descendants of what was once 
the Burroughs Large System -- is offered in configurations that are based on 
hardware implementations of that architecture alongside those that use 
"commodity" hardware and functionally simulate the same system.  Whether the 
entire machine architecture is implemented in hardware or software or a 
combination of both is a matter for the implementor to decide and a matter of 
market placement, not a matter for consideration in the development of the 
standard.  

Whether or not Unisys (for example, *and only* for example) finds it 
economically appropriate to dedicate resources to develop a *hardware* 
implementation of this (or any other) decimal floating-point format is 
irrelevant to whether or not Unisys (for example) finds reasons to support the 
format in one or more languages, and it is also irrelevant to whether or not 
Unisys decides to directly support the format *in the architecture* (wehether 
that support be through a hardware or a software approach, and whether or not 
any distinction between a hardware and a software approach was actually visible 
to the end user to begin with).   

I believe that is an implementor-independent, platform-independent issue.  
Whether arithmetic using a given standardized format is particularly efficient 
-- or particularly inefficient -- in a particular implementation on a 
particular platform is a matter between the vendor of the software using the 
format and its end user.  

For any such standardized format, I believe there will be hardware 
implementations for the arithmetic, and I believe there will be software 
implementations. Which one an implementor finds most suitable for which market 
segment, which one performs better under what circumstances, and what "Eureka!" 
moments an individual implementor might or might not be expected to encounter 
in his efforts to improve performance and marketability should not, I believe, 
be the concern of a standards committee.    

As to the conclusion "[I]n the absence of such evidence ... we, as a standards 
body, should standardize the arithmetic but not the formats":  

From the standpoint of the COBOL language, one thing that is attractive about 
Decimal128 is the *portability of the format*.  The standardization of the 
arithmetic rules is a peripheral bonus to the definition of a single *format* 
(or set of formats).   Portability of data and portability of applications is 
contingent on portability of the format in which it is encoded, and portability 
of a format is contingent on its singularity.  

Another symbiotic aspect of Decimal128 and COBOL is that Decimal128 is an 
encoding of values that are understood to be expressed in base-10 units in a 
format in which the values are actually encoded in base-10 units.  Conversion 
to and from other decimal encodings into and from Decimal128 will clearly be 
more efficient than encoding into and from encodings that are not encoded 
directly "digitwise".  

Encoding decimal significands in something other than a decimal format has at 
least a conceptually, and I believe an actual, deleterious impact on the 
performance of arithmetic when the scale factors of the operands must be 
adjusted, as the scaling would require actual multiplication or division by a 
power of ten to adjust the exponents; for decimal encodings, it seems to me, 
the significand adjustments are a simple digit shift.  

As to implementation difficulty:  the amount of effort an implementor puts 
forth, or needs to put forth, to produce an implementation conforming to a 
given design, and what further effort that implementor needs to put forth to 
improve the efficiency and cost-effectiveness of that implementation both for 
the implementor and for the implementor's customers, is a marketing decision 
that rightly belongs in the purview of  the implementor, not the standard.  

<<He also asked if there are any likely customers for Decimal128 if it is there 
intention to replace all (or most) of their existing decimal storage formats 
(which range in size from 4 to 121 bits) with the Decimal128 format or if they 
merely see the Decimal128 format as a computation format.>> 

I would expect, with the availability of Decimal128 as a standardized format, 
those COBOL sites who are concerned about application and data portability and 
that are now using implementor-defined formats for both fixed-point and 
floating-point operands in a fundamentally-decimal application, would be likely 
customers for the Decimal128 *formats* in exchange environments as a first 
priority, and for migration to the IEEE 754r arithmetic rules as a second 
priority.  

I would most certainly *NOT* expect users to change their programs so that 
every single decimal-format item was replaced by a Decimal128 item.  Those that 
are appropriately changed would be changed; those that are not appropriately 
changed would not.  

COBOL currently has portable formats for decimal items; what it does not have 
is a standard format that can contain an arbitrary value to 32 digits of 
precision with a power-of-ten exponent range of two thousand.  There are cases 
in COBOL applications where such ranges are appropriate, and there are cases in 
which they are not.  

I am forced to conclude that the answer to the question, as asked, is that the 
question has no meaning.   There are multiple orthogonal issues expressed in it 
that are presumed to be related. Consider:  

Decimal128 is of value as an industry-standard format for purposes of 
information exchange within a program that does no arithmetic at all.  Whether 
the arithmetic rules of IEEE 754r are followed in that program is of no 
interest.    

Decimal128 is of value as an industry-standard *internal* format for arithmetic 
purposes in programs in which all of the data is expressed in character- or 
digit-oriented forms.  There may be no particular need for the particular 
program to *exchange* information in Decimal128 format.    

Using the same format for *both* purposes -- as an exchange format so that 
format conversions become unnecessary when data is manipulated arithmetically 
-- is precluded by the "either-or" nature of the question as posed.  Use for 
exchange and use for arithmetic are by no means mutually-exclusive concepts, 
nor are they dependent on each other in any way.  

Moreover, given COBOL's inter-program communication capabilities, all four of 
these possible Decimal128 usage scenarios -- exchange only, arithmetic only, 
both exchange and arithmetic, and no use of Decimal128 at all -- could occur 
*in the same COBOL compilation unit*, to say nothing of the same application, 
or in different applications at the same site, depending on the *particular* 
requirements of the program, the application, or the customer in the 
*particular* context.     

     -Chuck Stevens
     -Unisys MCP Languages
     -Secretary, INCITS/J4 
     -Member, US delegation to ISO/IEC JTC1/SC22/WG4

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for se only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.