From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 23 09:54:29 2011 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 CD76F3568FC; Fri, 23 Sep 2011 09:54:29 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-3-a-1.mail.uk.tiscali.com (mk-filter-3-a-1.mail.tiscali.co.uk [212.74.100.54]) by www.open-std.org (Postfix) with ESMTP id E12E33568E7 for ; Fri, 23 Sep 2011 09:54:26 +0200 (CEST) X-Trace: 674062179/mk-filter-3.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/2.101.19.94/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.101.19.94 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFs6fE4CZRNe/2dsb2JhbAAMNqpcAQEBAQIBAQEBJCwbChELDQsJFg8JAwIBAgEVMAYNBgICh3UGtHeGfQSTUoUOMYtz X-IronPort-AV: E=Sophos;i="4.68,428,1312153200"; d="txt'?scan'208";a="674062179" Received: from unknown (HELO [127.0.0.1]) ([2.101.19.94]) by smtp.tiscali.co.uk with ESMTP; 23 Sep 2011 08:54:25 +0100 Message-ID: <4E7C3B1F.2080407@stfc.ac.uk> Date: Fri, 23 Sep 2011 08:54:07 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.4535) Provisional result of WG5 interps ballot 1. References: <20110922161605.9F7EF3568F8@www.open-std.org> <1316716254.27387.65.camel@math.jpl.nasa.gov> In-Reply-To: <1316716254.27387.65.camel@math.jpl.nasa.gov> Content-Type: multipart/mixed; boundary="------------050605060607090005020804" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------050605060607090005020804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Van Snyder wrote: > I withdrew my objection to F08/0010 yesterday. Sorry to have overlooked this. I have changed your vote and that of Malcolm to YES. John. > > On Thu, 2011-09-22 at 09:15 -0700, John Reid wrote: >> >> F08/0010 >> Cohen comment >> Van's assertion that the "argument" parts of the edits is covered by >> 12.5.2.13p1(1) is mistaken - 12.5.2.13p1(1) does not cover the case of >> a subobject of an allocatable being argument associated, and (3) does >> not cover the case when the object has the TARGET attribute (that is >> explicitly excluded). Deleting those parts would change my vote to NO. >> (There is some scope for wordsmithing to avoid precisely the cases >> that can be proven by theorem to be covered by various existing bits >> of 12.5.2.13, but in my view this would make the edits more >> complicated to no good purpose, so I would probably still want to vote >> NO if such changes were made.) >> >> Snyder NO vote >> The "argument" parts of the edits are not necessary; they are covered >> by 12.5.2.13p1(1) and (3). We should have imposed a similar >> requirement for construct association, but did not, so the remainder >> of the edits are germane. >> > > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3 --------------050605060607090005020804 Content-Type: text/plain; name="N1878-2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1878-2.txt" ISO/IEC JTC1/SC22/WG5 N1878-2 Result of the interpretations ballot 1, N1876 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N vote fails. Returned to J3 for further work. F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0030 0048 0085 0091 0096 0105 0110 0121 0123 0124 Bader Y Y Y Y Y Y Y Y Y Y Cohen C Y Y Y C Y Y Y Y Y Corbett N Y Y Y N Y N C Y Y Long Y Y Y Y C Y Y C Y Y Muxworthy Y Y Y Y N Y Y Y Y Y Reid N Y Y Y C Y Y Y Y Y Snyder N C Y Y N Y Y N Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Xia Y Y Y Y Y Y Y Y Y Y Result N C Y Y N Y Y N Y Y F03/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0128 0001 0002 0003 0004 0006 0007 0008 0009 0010 Bader Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y N Y Y Corbett Y Y Y Y Y Y Y N Y Y Long Y Y Y Y Y Y Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y N N Y Y Y Y Y Snyder Y Y Y Y Y Y C N Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Xia Y Y Y Y Y Y Y Y Y Y Result Y Y Y N N Y Y N Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0011 0013 0014 0015 0016 0017 0018 0019 0020 Bader Y Y Y Y Y N Y Y Y Cohen Y Y C Y Y Y Y Y Y Corbett Y Y Y Y Y Y Y Y Y Long Y Y N Y C C Y Y Y Muxworthy Y Y Y Y Y Y Reid Y Y Y C C Y Y Y Y Snyder Y Y Y Y Y Y C Y Y Whitlock Y Y Y Y Y Y Y Y Y Xia Y Y Y Y Y Y Y Y Y Result Y Y N C C Y Y Y Y comments and reasons for NO votes .................................................................... F03/0030 Cohen comment: Van's comment on 13.7.1 also being wrong is well taken, but refers to an issue that is separate from that considered by the interpretation. In my opinion 13.7.1 should be fixed in a separate interp, e.g. F08/0008 which actually does ask about intrinsic functions. Corbett NO vote The proposed interpretation and edits make no sense unless one assumes that the intent is to redefine and repurpose the function IEEE_SUPPORT_DATATYPE. If that is the intent, the interpretation and edits should address the issue directly instead of modifying seemingly unrelated text. Reid NO vote I agree with Bob Corbett that it is inappropriate to refer to IEEE_SUPPORT_DATATYPE since 14.9 makes it clear that support requires: "for at least one rounding mode, the intrinsic operations of addition, subtraction and multiplication shall conform whenever the operands and result specified by IEC 60559:1989 are normal numbers". To avoid a conflict with IEC 60559:1989, I suggest that the words in the first two bullets points of 14.3 be changed to apply only to cases where the operands are normal numbers. Snyder NO vote Edits could be construed to introduce a contradiction between 13.7.1 and 14.3. My vote would be yes if the penultimate sentence of 13.7.1p2 began "If support is provided and an infinite result...." .................................................................... F03/0048 Snyder comment: In the second paragraph of the answer, "possibility" should be "possibly" .................................................................... F03/0096 Cohen comment I agree that adding "in the same statement" to the end of the sentence in the second edit would be an improvement. I do not agree with the comments about SIZE=; both it and the input-items depend on the input file contents, but I don't see how it depends on the input-items directly. Corbett NO vote The second proposed edit prohibits the value of a SIZE= specifier from depending "on any ." That seems to require the value of a SIZE= specifier to be constant. Long comment The wording of the second edit suggests that the SIZE= value returned cannot depend on the input list, which is not what is intended. I think this can be corrected by adding " the values of" after "shall not depend on" in the edit. Muxworthy NO vote I agree with Robert Corbett's comment. Reid comment In the second line of the question change "an" to "a". Snyder NO vote My vote would be yes if the sentence introduced at the end of 9.12p5 included "in the same statement" (as does the existing sentence in that paragraph). .................................................................... F03/0110 Corbett NO vote The last sentence of the proposed interpretation contradicts the conformance clause of the standard. .................................................................... F03/0121 Corbett comment Fortran programmers need the functionality proposed in the request for interpretation. The mechanism proposed corresponds to what many Fortran programmers already assume to be the case. The committee should either adopt the proposed mechanism or provide an alternative mechanism. Long comment My reading of the original question included a desire to say that the result value for REAL(X, KIND=wp), for a particular value of X, is the SAME result value independent of the context in which the function reference appears. After all, it would not really be a "function" in the normal sense if that were not the case. The subsequent discussion in the ANSWER section could cast doubt on whether this basic requirement is actually true. It would be better to explicitly state that REAL for a particular set of arguments always returns the same result value independent of the context. Snyder NO vote Un ugly unsatisfying answer that appears to have been crafted by a politician trying to evade the real issue, perhaps because of a deficit of knowledge of issues important in numerical analysis. I don't understand the necessity for REAL not to do what it says it does. The answer simply confirms a contradiction. My answer would be yes if the answer were that REAL(,KIND=k) returns a value that is the same value that a REAL variable of kind k would have, if were to have been assigned to that variable. After all, REAL is a function, and therefore has a result variable to which its result value is assigned. .................................................................... F08/0003 Reid NO vote There are too many edits for what is really a small correction. It would be much better to leave all the optional DIM arguments as optional and use the form of words used for COUNT. This would more than halve the number of edits. .................................................................... F08/0004 Reid NO vote As the question points out, the descriptions of arguments apply to actual arguments. In the example, Target is a disassociated pointer so TARGET in the description is present and is a disassociated pointer. 12.5.2.12 is not applicable here because it is all about dummy arguments. Case (vi) is applicable and tells us that the result is false. No edits are needed. .................................................................... F08/0007 Snyder comment One's complement is not the only case in which signed zero could arise. Sign magnitude (e.g. IBM 7094) or decimal machines (IBM 7010 etc.), or XS3 machines (Univac 1005). But these are irrelevant now. .................................................................... F08/0008 Cohen NO vote The quoted text in 13.7.1 is just wrong and needs to be fixed. Corbett NO vote If the statement in the standard that "the flag IEEE_INVALID shall signal" is, as is stated in the interpretation, is incorrect, the text of the standard should be altered to reflect that. Snyder NO vote See answer to F03/0030. There are no edits here, but arguing that the requirement in 13.7.1p2 does not apply admits a contradiction. My answer would be yes if there were an edit causing the penultimate sentence of 13.7.1p2 to begin "If support is provided and an infinite result...." .................................................................... F08/0014 Cohen comment: Bill raises 3 possible "options" of the interpretation: (1) and (3) are equivalent (they both avoid doing the thing that is forbidden, who cares HOW the user avoids breaking the rule!) and (2) is contradicted by the existing text in the standard, so I see no quandary. Long No vote The proposed edit is to add this text: "A vector-subscripted array section shall not be finalized by a nonelemental final subroutine". This is stated as a requirement on the user (program). It is unclear to me what this really means. Here are some options that come to mind: 1) For a type that specifies final subroutines, if a vector-subscripted array section of that type appears in a context where it would be finalized, the type shall specify an elemental final subroutine. 2) For a type that specifies final subroutines, if a vector-subscripted array section of that type appears in a context where it would otherwise be finalized, the section is not finalized if there is no elemental final subroutine. 3) For a type that specifies final subroutines, a vector-subscripted array section of that type shall not appear in a context where it would be finalized unless the type specifies an elemental final subroutine. .................................................................... F08/0015 Reid comment In the edit, delete "confusing". Edits go into the corrigendum, where we do not include any explanation. .................................................................... F08/0016 Long comment In the third line of the ANSWER, there is a typo: "copvers" -> ""covers". Reid comment There is a typo in the ANSWER, 'copvers'. .................................................................... F08/0017 Bader NO vote: As specified in the NOTE there, the edit is intended to be subsumed by edits in F08/0018. Long comment The discussion section paragraph is: "The subroutine test_add does not do anything useful other than to set the IEEE_OVERFLOW flag when x+y would overflow." This is a bit of a shock, since almost all compilers would, in fact, not perform the addition at all in test_add. Certainly we are not intending to imply that this common optimization is now illegal. Subroutine test_add contains no references to the IEEE modules. I would prefer to either delete this paragraph from the ANSWER, or to delete the end of the sentence following "useful". Further, the calls to the IEEE routines in the caller are a distraction from the point of the question, and could be deleted as well. .................................................................... F08/0018 Snyder comment Edits in F08/0018 subsume those in F08/0017 --------------050605060607090005020804--