[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two technical questions on IEEE Std 754-2008



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)

        Charles,

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

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

        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.

        Yours,

                                Dan


754 | revision | FAQ | references | list archive