From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Aug 24 11:24:11 2016 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 5601D357139; Wed, 24 Aug 2016 11:24:11 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (bvdeuz19.secure.ne.jp [180.222.80.19]) by www.open-std.org (Postfix) with SMTP id 5A4C13568F8 for ; Wed, 24 Aug 2016 11:24:06 +0200 (CEST) Received: (qmail 65782 invoked from network); 24 Aug 2016 18:24:04 +0900 Received: from unknown (HELO Maru10) (218.42.159.105) by 0 with SMTP; 24 Aug 2016 18:24:04 +0900 Message-ID: From: "Cohen Malcolm" To: References: <20160824084711.4E34C357139@www.open-std.org> In-Reply-To: <20160824084711.4E34C357139@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.5782) (j3.2006) edits to clarify SQRTtreatment ofnegative zero, for comments Date: Wed, 24 Aug 2016 18:24:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: owner-sc22wg5@open-std.org Precedence: bulk 1. There is no negative zero as an actual argument to complex SQRT. The actual argument is the complex value and this is not a negative real zero, in fact it is not even real. If it was otherwise this would be a NEW FEATURE requiring WG5 approval. A careful reading of the current text already reveals the answer you want, it is not ambiguous, contradictory, or even wrong. So the edit to SQRT is not strictly necessary, though as I said I do not actively object. I do think you should first report non-compliant behaviour direct to the vendors concerned though, as this is going to be the quickest way to get the situation corrected. 2. The "logic" of the compatibility subclauses, is that they describe the incompatibilities. I do not know why you think they are "accumulative" since each one fully describes the incompatibilities between F2015 and the referred-to older standard. Please read the F90 and F77 subclauses both of which correctly describe the incompatibility with SIGN. This needs to be done in a similar fashion for SQRT. Cheers, -----Original Message----- From: Anton Shterenlikht Sent: Wednesday, August 24, 2016 5:47 PM To: sc22wg5@open-std.org Subject: [ukfortran] (SC22WG5.5782) (j3.2006) edits to clarify SQRTtreatment ofnegative zero, for comments >From: "Cohen Malcolm" > >I would prefer to leave the "principal value" wording alone. > >I also prefer to leave the "When the real part of the result is zero" >wording alone. Unless you enjoy posing maths questions of people reading >the standard to work out whether anything changed. > >I also don't think this is necessary - the likely reason vendors did not >spot the change in semantics from previous Fortran standards (77 and 90 >both >forbid negative real zero being treated differently from positive real >zero) >is just that the change in semantics occurs without any wording change in >SQRT itself. That is, the word "sign" in the description does not refer to >the SIGN intrinsic directly, however since the SIGN intrinsic returns the >"Magnitude of A with the sign of B", it is clear that "the same sign as" a >distinguished negative real zero means a negative value. It could well be >more effective to point out to the offending vendor(s) that they overlooked >this Fortran 95 change in semantics than to edit SQRT like this. (I don't >actively object to editing SQRT to make it more obvious though, if that's >what people want; just that it's not necessary.) [56:21-25 4.4.3.2p3] is very clear on the rules: "Processors that distinguish between positive and negative zeros shall treat them as mathematically equivalent ... as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished." SQRT does not "explicitly specify" that negative zero is distinguished. Implicitly, following the SIGN logic, yes. But not explicitly. So strictly following [56:21-25] SQRT does not distinguish between positive and negative zero. So it seems to me the wording must be changed to explicitly specify that negative zero is distinguished. >The paper needs to add text to the Fortran 90 compatibility and Fortran 77 >compatibility subclauses to mention the change in semantics (close to where >we talk about SIGN). I understood the logic of compatibility subclauses as accumulative, i.e. Fortran 90 compatibility clause lists only differences not already mentioned in the preceding subclauses for f95 and f03. Is that wrong? Is the aim to list the full list of differences between f08 and f77 under Fortran 77 compatibility? >Finally, with luck and a fair breeze 16-007r2 should be available early >September so I recommend waiting until then so that you can produce edits >against what will be the actual live draft. Thank you Anton _______________________________________________ ukfortran mailing list https://lists.accu.org/mailman/listinfo/ukfortran -- ........................Malcolm Cohen, Nihon NAG, Tokyo.