I got the formulae from Page 8 in the first place. I know the formulae I used look odd; my reasoning here was to come up with formulae for the maxima that "made sense" to the COBOL user -- for decimal, <n> digits of 9's as an integer, multiplied by an appropriate power of ten (alternatively presented as a "classic" scientific-notation number to the same precision, and still evaluating to an integer), and for binary, the difference between two integer powers of two. The subnormal minimum formula is I think a straightforward algebraic reduction. The normal minimum formula was used basically as is with substitution of (1-emax) for emin (as specified on page 7). |
What we're planning to provide for the decomal formats for COBOL arithmetics and data conversions is ONLY the decimal encodings, and ONLY finite numeric values in those encodings. We are not planning to format information into the binary encodings, nor are we planning to have them recognized as numeric if such information comes in from "outside". That may come in a later revision, but not at this point.
We do provide, however, for the recognition of NaN's and infinities, but they are identified as NOT numeric. The identification of such data is straightforward.
The result of passing non-numeric data into an arithmetic operation (or environment) is a fatal exception condition.
The problem is that we also wish to treat binary encodings in decimal formats (which might come in as user data from other systems) as NOT numeric for our purposes, just as is clearly and simply accomplished with NaN's and infinities. We need to identify them as the third subset of information in the decimal interchange formats (along with NaN's and infinities) that does NOT qualify as numeric.
In order to do that, we will need to be able to detect them in order to handle the appropriate exceptions. COBOL won't "produce" values in that encoding, but it might receive one from "outside" the program. The result of attempting in COBOL to use a binary encoding (or a NaN or an infinity) into an arithmetic operation is a fatal exception condition complaining of data incompatibility.
A boolean isDecimalEncoding function (and for the future isBinaryEncoding) would have been really useful, but I don't see one.
A "processing environment" that supports only the binary encoding of decimal formats in its processes can still be "handled" -- it would be part of the "processor" (most likely support software) to convert operands from the decimal encodings supplied by the program to the binary encodings used in arithmetic, and to convert the binary encodings of the results to decimal for delivery to the program.
But as far as COBOL is concerned, finite numeric values in the decimal interchange formats are all encoded in decimal, and anything else is not numeric, at least for this revision of the standard.
> To: charles.stevens@xxxxxxxx
> CC: stds-754@xxxxxxxxxxxxxxxxx; forieee@xxxxxxxxxxxxxx
> From: forieee@xxxxxxxxxxxxxx
> Subject: Re: Two technical questions on IEEE Std 754-2008
> Date: Tue, 22 Feb 2011 13:19:19 -0800
> > From: Charles Stevens <charles.stevens@xxxxxxxx>
> > To: <stds-754@xxxxxxxxxxxxxxxxx>
> > Subject: Two technical questions on IEEE Std 754-2008
> > Date: Tue, 22 Feb 2011 12:56:26 -0700
> > Background: I am responsible for the architecture of enhancements to ISO/I=
> > EC 1989:2002=2C the COBOL language standard=2C to make use of five of the i=
> > nterchange formats from IEEE 754-2008 in both encoding/decoding and in arit=
> > hmetic. We are preparing a new standard=2C it has completed its first inte=
> > rnational ballot=2C and I have a couple of questions relative to these form=
> > ats.
> > Question 1:
> > I have calculated the maximum magnitudes for decimal64=2C decimal128=2C bin=
> > ary32=2C binary64=2C and binary64 using what I believe to be equivalent for="">> > mulae (for clarity of presentation). I need verification both of the corre=
> > ctness of the formulae (not for calculability using the arithmetic rules of=
> > IEEE 754) and the results:
> > Decimal formats: ((10**p - 1) * (10**(emax+1-p))
> > Binary formats: (2**emax+1) - (2**(emax+1-p)
> All the formulae for these numbers can be found on page 8
> of the 2008 document. You state them in an odd way but
> you have them correct. And my examination of the values
> you instantiate into these formulae for each of the basic
> formats indicates that you have them correct as well.
> > . . .
> > Question 2:
> > Is there a simple way to determine=2C by examination of a datum in a decima=
> > l interchange format without foreknowledge of the encoding used to produce =
> > it=2C whether it is in the binary encoding or the decimal encoding? I have=
> > n't been able to figure it out with a careful examination of the "combinati=
> > on" field. Or does a given value in one encoding always have the same bit =
> > representation as a cohort with the same exact value in the other encoding?=
> > (I can envision that possibility).
> > Thanks for any input you can provide on these two questions.
> > Sincerely=2C
> > Charles C. Stevens =
> The answer to this is rather more involved than it
> should be.
> The simple answer is that you should never have to
> know which encoding is being used. Indeed, on page
> 18, clause 5.2, paragraph 2, it says so in so many
> We have gone out of our way to provide you with an
> instruction set sufficiently rich that you should
> never need to do any bit twiddling to answer any
> Still, your point is well taken & it is something
> we discussed at length. Given the decimal reencoding
> operations provided in section 5.5.2, the implication
> is that you might want to convert from one encoding
> to the other. And somehow you have to know when it
> is needed.
> But it is also clear that you will know at the time
> of the installation of your compiler what sort of
> hardware it runs on & what sort of encoding is used
> on that hardware.
> Therefore, for (otherwise) portable software each
> language should provide a boolean (or enumeration)
> type function that answer the question of what sort
> of encoding is used on that hardware. Thus, portable
> code written to interconvert decimal data among
> heterogeneous machines can evaluate this encoding
> function on each machine to decide if reencoding is
> needed on the transfer of data.
> We provided for such a standard predicate on earlier
> versions of the draft but it appears not to have
> survived to the final document.
> Still, this is the method. Define such a predicate
> as standard for all conforming Cobol systems & use
> that to manage the encodings.
> If you do it that way you STILL don't have to do any
> bit twiddling. The reencoding functions are provided
> for you.
> I hope that is an acceptable answer.