Rounding (COBOL and otherwise)

As a follow-up to the other "threads" on ROUNDING, I have posted a page that
 is
an (edited) version of a paper discussed by J4 in 1993 on "rounding" and som
e
other possible (and existing in other languages and software) approaches.

Thank you to Jordan Wouk for providing his original paper to me.

The edited online version may be viewed at:

http://home.comcast.net/~wmklein/DOX/RNDG.htm

It should be noted that even as the 2002 Standard was revised and delayed, i
t
was felt that there was insufficient "user-demand" to extend (much less modi
fy)
the existing (traditional for already 30 years in 1993) rules for ROUNDING.
None of this was done for the 2002 Standard and none of it is proposed (much
less in progress) for the 2008 Standard.

--
Bill Klein
wmklein <at> ix.netcom.com

As Bill points out, this isn't in the 2002 standard and isn't planned for
the 2008 "base" standard.  If WG4 were to approve the project, it might end
up as a Technical Report which has the force of an amendment (even to the
2002 standard, though that's unlikely).

I can't help but feel that incorporating (by reference) the rules for
Language Independent Arithmetic as defined in international standards as a
user-specified alternative to Standard and Native arithmetic is a greater
need.   I view enhancing the ROUNDED syntax as of secondary importance; the
rules for ROUNDED would have to follow the historical COBOL precedents in
terms of defaults.  For a conforming implementation of LIA, additional
ROUNDED syntax *would* be required, and would have to work exactly as
specified according to LIA.

Once that was done, the additional ROUNDED syntax and semantics could
reasonably be expanded to include "standard" and "native" arithmetic, and
whatever ROUNDED mechanisms were deemed desirable at that point.

But given potential projects in this general area, I think "Language
Independent Arithmetic" is of much greater importance, and that "enhanced
ROUNDED syntax" could, and I would argue should, ride in on its coattails.
I don't think the former is practical until both a *basic* format for
128-bit binary floating-point items and a *rigorous* set of arithmetic rules
that cover all the bases (no pun intended) applying to such items have made
it into an International Standard that the COBOL standard can reference.  So
far as I know that hasn't happened yet, much as I would like to see that
happen.

-Chuck Stevens

On Mon, 30 Aug 2004 22:35:13 -0500, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>As a follow-up to the other "threads" on ROUNDING, I have posted a page tha
t is
>an (edited) version of a paper discussed by J4 in 1993 on "rounding" and so
me
>other possible (and existing in other languages and software) approaches.
>
>Thank you to Jordan Wouk for providing his original paper to me.
>
>The edited online version may be viewed at:
>
> http://home.comcast.net/~wmklein/DOX/RNDG.htm

Thank you for posting the page.

>It should be noted that even as the 2002 Standard was revised and delayed, 
it
>was felt that there was insufficient "user-demand" to extend (much less mod
ify)
>the existing (traditional for already 30 years in 1993) rules for ROUNDING.
>None of this was done for the 2002 Standard and none of it is proposed (muc
h
>less in progress) for the 2008 Standard.

Isn't Standard Math under discussion for 2008? Someone will have to
define how intermediates are rounded, hopefully only when absolutely
necessary. LIA-1 gives the implementor three choices. Seems to me
there should be one, if programs are to produce the same result when
ported to another compiler.

I thought that you had access to the 2002 Standard

"Standard Arithmetic" (not "Standard Math") is a part of the (already approv
ed)
2002 Standard. No one asked for - nor does it include - any changes to the w
ay
the "ROUNDED" phrase works (and has worked to the approval of all users
communicating to the Standards committees since 1960 or so).

Furthermore, during the time when J4/WG4 were soliciting ideas for the next
(2008) Standard, (a fact I advertised here) no one indicating any problems w
ith
the ROUNDED phrase.

As Chuck has already indicated, you could certainly suggest such to J4/WG4. 
 My
guess is that (outside of POSSIBLY providing LIA support - probably post-200
8),
there would be minimal support for any change to this phrase.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
 news:lit9j0dbqtfr351265jkg7dft4qe8fls0p@
4ax.com...
> On Mon, 30 Aug 2004 22:35:13 -0500, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
> 
>
> Thank you for posting the page.
> 
>
> Isn't Standard Math under discussion for 2008? Someone will have to
> define how intermediates are rounded, hopefully only when absolutely
> necessary. LIA-1 gives the implementor three choices. Seems to me
> there should be one, if programs are to produce the same result when
> ported to another compiler.

On Tue, 31 Aug 2004 21:50:16 -0500, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>I thought that you had access to the 2002 Standard
>
>"Standard Arithmetic" (not "Standard Math") is a part of the (already appro
ved)
>2002 Standard. No one asked for - nor does it include - any changes to the 
way
>the "ROUNDED" phrase works (and has worked to the approval of all users
>communicating to the Standards committees since 1960 or so).

Yes, it's there for fixed-point. I was referring to floating-point
being under consideration for 2008, or at least on the wish list.

There was a tiny change made. Standard Arithmetic says intermediates
must be truncated. Under Native Arithmetic, it's likely they're being
rounded. That doesn't bother me because the high precision of Standard
intermediates minimizes loss of information.

>Furthermore, during the time when J4/WG4 were soliciting ideas for the next
>(2008) Standard, (a fact I advertised here) no one indicating any problems 
with
>the ROUNDED phrase.

I didn't think of it at the time.

>As Chuck has already indicated, you could certainly suggest such to J4/WG4.
  My
>guess is that (outside of POSSIBLY providing LIA support - probably post-20
08),
>there would be minimal support for any change to this phrase.

Chuck described in detail why he thought ROUNDING should piggy-back on
other numerical issues.

Had I noticed that exponentiation was limited to integers in the range
0 through 4, I would have recommended it be changed to work like other
languages. Given that Cobol has a LOG function, how hard could that
be?

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
 news:92kcj0d2sh08hu9eqhjqe550fhrs9031rp@
4ax.com...
 
discussion 

> You talked of looking for a binary floating-point SIDI. Sounds to me
> like development.

No.  Please don't misquote me.  The behavior of SIDI's *and* of standard
arithmetic is already defined in the standard.  What I think what you are
referring to is the possibility of using a BINARY128 format as defined in
the draft for IEEE 754 as a *container* for a SIDI.

> The 'rounding' rule for decimal SIDIs is truncation. I was referring
> to binary SIDIs, if we get them in the future.

SIDI's are *decimal* by definition.  You've already got what you want in the
FLOAT usages, and you're wrong about the rounding rules.   Standard COBOL
"rounded" logic applies; that's why we'd need new syntax (and thus
associated code) to handle the "other" rounding rules.

> You're talking about rounding the final result; I'm talking about
> rounding intermediates.  For example:

Start over with 32 decimal digits of precision.  18 digit maxima are *so*
1960's.

-Chuck Stevens

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
 news:9uebj0pjvmf1g5l4e737j5ia0n2hpegnej@
4ax.com...

> When it comes to rounding intermediates, LIA lets the implementor
> choose one of three methods. As a result, a program ported to another
> platform could produce different results. I thought a goal of
> standardization is to prevent that.

That is why I would recommend enhancement of the ROUNDED clause to include a
number of possibilities including the current defaults.  Just as would be
the case today if BINARY132 were used to implement SIDI's, object code would
be generated to account for the rules differences.

> Thank you for the detailed description of your thinking on the
> subject.

You're welcome.

-Chuck Stevens