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

Re: Two technical questions on IEEE Std 754-2008



From: "William M Klein" <wmklein@xxxxxxxxxxxxx>
To: "'Dan Zuras IEEE'" <forieee@xxxxxxxxxxxxxx>
Cc: "'IEEE 754'" <stds-754@xxxxxxxxxxxxxxxxx>,
      "'Charles Stevens'" <charles.stevens@xxxxxxxx>
Subject: RE: Two technical questions on IEEE Std 754-2008
Date: Thu, 24 Feb 2011 17:48:00 -0600

-----Original Message-----
<snip>

      That you don't seem to be interested in using both
      encodings wastes that latter time.  That you don't
      seem to be willing to support decimal even to the
      point of changing the fundamentals of the arithmetic
      WRT NaNs & infinities wastes the rest.
Dan
-----End Original Message-----

Dan,
  I am curious, although COBOL is no longer "strictly" limited to "business"
applications (cf. the "B" in COBOL), this is certainly our historical (and
even today MAJOR) usage.

Can you give me some examples of how/or why a business application might
want to do "numeric" operations on a Nan or Infinity?

. . .

However, I am quite serious in wanting to know what FEATURES you think we
are missing that our users will/would want.

P.S.  My personal guess is that if any of these features ARE of significant
interest to COBOL users, that implementors will provide them as extensions -
until the next revision of the Standard. It is only those features of
minimal or no use that tend NOT to get implemented - Especially if the
environments provide either software or hardware support for "fully
conforming" 754 support.


        William,

        I gave an example of financial forecasting in
        my note of Wed, 23 Feb 2011 08:47:45 PST.

        I will quote it again if you like but it comes
        down to an issue choosing among probablities
        that are wildly different & can get very small.
        One compares the ratios (or differences of the
        logs) & chooses one from another.  These ratios
        can get very large (up to & including overflowing
        to infinity).  In which case the ratio is ignored
        & the larger of the two probablities is chosen.
        Or they can get very small (down to & including
        zero).  In which case the denominator is chosen.

        The latter causes no problems for anyone.  The
        former also causes no problems in systems that
        handle infinity as any other number.

        For financial calculations (including forecasting)
        the handling of NaNs is less interesting.  Indeed,
        they show up in Monte Carlo models only when the
        infinities are miss handled & one tries something
        like inf - inf.  So, in this case, the way Cobol
        handles NaNs is quite similar to how 754 handles
        them when the invalid attribute is enabled & some
        sort of fatal (or diagnostic) trap handler is
        called.

        I suggested this to Charles as a reasonable way
        to go that only changes the defaults for 754 not
        the arithmetic itself.  It does not seem to be in
        keeping with what you have in mind.

        Aside from financial forecasting, I agree that
        the use of NaNs & infinities is largely not
        meaningful for any number that has units attached
        to it (femtopfennigs, footpoundals/fortnight,
        shekels/month, that sort of thing).  If Cobol
        knows that units are attached to a number then
        interrupting the flow of execution to deal with
        infinities is reasonable.

        Again, I suggested to Charles that this behavior
        is quite similar to alternate exception behavior
        for 754 when the overflow attribute is enabled.
        As I suspect Cobol already chokes on a divide by
        zero, this could be handled by alternate exception
        handling for the divideByZero attribute.

        All of these things are described in clause 8 of
        the current 754 document.

        Should Cobol choose to use these mechanisms to
        'wedge' 754 into the Cobol philosophy, my personal
        opinion is that it would be a much cleaner way to
        go than altering the fundamental behavior of the
        arithmetic.  It would still mean that Cobol fails
        to conform.  But I think it would be much more
        acceptable to everyone as only a slight & (given
        Cobol's history) understandable variance.

        That was my intent anyway.

        Perhaps it is insufficient to do the job.

        As for FEATURES with a capital FEATURE, I am
        entirely unqualified to know how Cobol's behavior
        affects its customers either for good or for ill.
        I'll leave that for others to judge.  I am merely
        trying to preserve that which is best in the
        arithmetic without stepping to much on the old
        man's toes.

        I don't think I'm doing very well.

        Yours,

                                Dan


754 | revision | FAQ | references | list archive