From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Thu Dec 21 12:29:44 2017
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 1D51B3589A8; Thu, 21 Dec 2017 12:29:44 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from smtp-out-6.tiscali.co.uk (smtp-out-6.tiscali.co.uk [62.24.135.134])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.open-std.org (Postfix) with ESMTP id AC95D356E19
	for <sc22wg5@open-std.org>; Thu, 21 Dec 2017 12:29:41 +0100 (CET)
Received: from [192.168.1.10] ([212.139.82.74])
	by smtp.talktalk.net with SMTP
	id Rz2eel9qV0NSRRz2eelwHA; Thu, 21 Dec 2017 11:29:36 +0000
X-Originating-IP: [212.139.82.74]
Subject: Re: (j3.2006) (SC22WG5.6011) RE: [ukfortran] IEEE_INT
To: 'WG5' <sc22wg5@open-std.org>
References: <20171220184752.684C5358283@www.open-std.org>
 <20171221004505.9257A358283@www.open-std.org>
From: John Reid <John.Reid@stfc.ac.uk>
Message-ID: <b5ef730e-6b17-5f83-52c2-09bcb0c3ebcc@stfc.ac.uk>
Date: Thu, 21 Dec 2017 11:29:33 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101
 Firefox/49.0 SeaMonkey/2.46
MIME-Version: 1.0
In-Reply-To: <20171221004505.9257A358283@www.open-std.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfBkx243jiJ+VpGkV/QOLEoc0TPUQKNreWjwrz0VbcrVlplKVyGUwCQQhgAvHeNAtI085h7zWX5BDnPNhmY5hLMpOenIauvBurxax5GoUq5zu2WNRV+Tr
 3rO4s753pi9re89uo7mQB/3Khdi8qyrz/kWP6GReAxzzIlKJVCQv/QRuaqan5pgKjlWOpqfLNHwBL7Q9XcZEi0gzOxy7dbYDFKI=
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Malcolm,

Thanks for the explanation. What I had missed was that "round to 
nearest" has been superseded by "round ties to even".

Cheers,

John.

Malcolm Cohen wrote:
> John Reid asks:
>> Do we have a problem with IEEE_INT (see 17.11.11 in N2137)?
>
> The answer to that is clearly NO.
>
> Furthermore, it would be entirely inappropriate to put special wording into a single function out of many.  And even more inappropriate to dump the exact same wording all over the standard.
>
> As it happens, if you want to know what the rounding modes mean, looking in 17.4 "The rounding modes" gives the exact correspondence between our rounding modes (and named constants) and the 60559 rounding-direction attributes, in paragraph 2.
>
> Cheers,
>