From Keith.Bierman@Eng.Sun.COM  Wed Jun  5 01:26:58 1996
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id BAA29153 for <sc22wg5@dkuug.dk>; Wed, 5 Jun 1996 01:26:56 +0200
Received: by mercury.Sun.COM (Sun.COM)
	id QAA24543; Tue, 4 Jun 1996 16:25:22 -0700
Received: from chiba.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13671; Tue, 4 Jun 1996 16:25:20 -0700
Received: from chiba (localhost) by chiba.eng.sun.com (5.x/SMI-SVR4)
	id AA15417; Tue, 4 Jun 1996 16:25:19 -0700
Message-Id: <9606042325.AA15417@chiba.eng.sun.com>
To: pichon@obspm.fr
Cc: sc22wg5@dkuug.dk
Subject: Re: (SC22WG5.1098) ROUND function in the French proposal about Fortran 2000 
Date: Tue, 04 Jun 1996 16:25:19 -0700
From: Keith Bierman QED <Keith.Bierman@Eng.Sun.COM>


If the number is half between the two nearest value, apply the Gauss Rule
    i.e. the last digit must be even. 
    For instance : ROUND(1250,2) must be 1200  whereas
                   ROUND(1350,2) must be 1400
             
Perhaps, a problem of consistency may occur if, with some compilers or I/O 
    libraries, this rule is not (yet) applied. 
    In fact, I have not checked this with the compilers available to me.

Well I **think** this is the IEEE default round to nearest mode, if I
understand you correctly. There are system which simply cannot
accomodate such rules using their native floating point
hardware. While I am perfectly happy to have Fortran demand IEEE
arithmetic, is this really the intent of AFNOR?

It seems odd that we'd continue to allow 2.0+3.0 be computed as 5.0
but we'd start specifying how the last bit should be rounded in edge cases.