From janshep@watson.ibm.com Mon Jul 17 12:28:39 1995 Received: from watson.ibm.com by dkuug.dk with SMTP id AA19597 (5.65c8/IDA-1.4.4j for ); Mon, 17 Jul 1995 22:31:30 +0200 Message-Id: <199507172031.AA19597@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4153; Mon, 17 Jul 95 16:30:13 EDT Date: Mon, 17 Jul 95 16:28:39 EDT From: "Janice C. Shepherd ((914) 784-6313)" X-Addr: H2-D52, Hawthorne I tieline 863 To: sc22wg5@dkuug.dk Subject: Results of X3J3 post meeting 133 006 letter ballot X-Charset: ASCII X-Char-Esc: 29 Mallory: please include this in the premeeting. Thanks Janice --------------------------------------------------------- X3J3/95- page 1 of To: X3J3 From: Janice C. Shepherd Subject: Results of the post meeting 133 006 letter ballot This document contains: 1) a summary of the vote counts and whether each item passed or failed 2) a list of the editorial corrections I made to defect items which passed 3) ballot comments (sorted by defect item #) If anyone finds any errors in the ballot results, please send them to me as soon as possible. Janice - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +-Yes votes | +-Yes with Comments | | +-No votes | | | +-Pass or Fail v: v: v: v Y:wc: N: P/F Defect# short description 12:4: 1: P 000101 Specification statements 13:4: P 000127 Is a module a global entity? 10:2: 5: F 000148 RANDOM_SEED, RANDOM_NUMBER 11:2: 4: P 000158 Leftmost (on a line) negative integer 10:5: 2: P 000173 Definition of elemental intrinsic subroutine 11:4: 2: F 000176 Definition of RANDOM_SEED 11:6: P 000186 Allowed values of POSITION= and STATUS= specifiers when changing BLANK= 14:2: 1: P 000193 Pointer actual arguments with the OPTIONAL attribute items passed: 6 items failed: 2 A total of 17 votes and two sets of comments (John R., Lawrie S.) were received. An item needed MAX(11,12) to pass (2/3 of 17 votes, more than 1/2 of 22 J3 members). So an item needed 12 yes votes to pass, but I failed some with this many yes votes when I thought it appropriate. While Henry and I both have comments we only count for one vote. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Editorial corrections made to items which passed: 101 Change DEFECT TYPE to "Interpretation" Add after the first sentence of the answer: "The changes are pervasive enough that they are best not attempted in a corrigendum to Fortran 90." 127 In the last paragraph under "Discussion for Answer 1:" change "" to "". Add quotes to quotations from standard. Fix comment in history to refer to Defect item 90. 173 In the first sentence of the edits section, change "sentence" to "sentences". In Question 2, the first word should be 'Alternatively" In the Discussion, delete the last word, "also". 186 Fix quotation marks in edits and remove quotes from values. In ANSWER 2, 2nd sentence, delete "to say" In Discussion, 6 paragraph, change "when unit" to "when a unit" 193 Add the keywords: argument - optional, POINTER attribute - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ballot Comments: Item Yes Who Comment # /No --------------------- 000101 Specification statements 101 Y Bleikamp Janice pointed out that since this is an F90 CCI request, that the answer should be phrased in terms of an F90 corrigenda, not in terms of F95. Although I agree with Janice, I think the proposed response gets the point across, and it is time to bury this one, especially since the submitter was a J3 member (Dick W.), (we won't confuse him), and by the time this is approved by WG5/ISO, F95 will probably already be a standard. If I knew for certain that WG5 wouldn't process the 3rd corrigenda until after the /interp group gets another chance to fix this per Janice's suggestion, then I would vote NO. 101 Y Hendrickson I agree with the Sheperd comments. 101 Y Martin The Shepherd comment should be added. Since no edits are proposed at this time, should this be classified as an interpretation? 0101 Y Rolison I basically agree with Janice's point that we need to address the RFI in terms of Fortran 90 and that adding the sentence she suggests would be a sufficient change to this RFI to get it off the books (and moved to the 008). However, note that while she voted No, I voted Yes to move this thing along. 101 N Shepherd While I agree with the concept of delaying the edits to Fortran 2000, the answer needs to address the issue in terms of Fortran 90 (it is a Fortran 90 RFI). Perhaps adding after the first sentence of the answer: "The changes are pervasive enough that they are best not attempted in a corrigendum to Fortran 90." --------------------- 000127 Is a module a global entity? 127 Y Adams Is a module a global entity? In the discussion for the answer, you have a typo in the changed text for 12.1.2.2.1. In the new text, change to . This is not very important, except it is an edit to go into the document. 127 Y Hirchert With respect to the language, I originally leaned in the direction Lawrie is championing and more recently have leaned in the direction of some of the extensions mentioned by Janice. However, with respect to this defect item, I believe that Rich Maine has the important point -- the document as it stands is not "broken"; i.e., it is not ambiguous, difficult to implement, or an impediment to plausible future extensions. As such, there is no excuse for modifying Fortran 90 retroactively. Let Janice and Lawrie's comments be considered for Fortran 95 or 2000. 0127 Y Rolison If Janice wants the text quoted from the standard to be indented AND surrounded by quotes then so be it. Indentation would be enough for me. The correction (in my notes from the meeting) to correct "" to "" in the new text quoted from the standard in the Discussion for Answer 1 did not get applied (almost certainly because I failed to get the updated copy of the paper to Mallory. Sorry guys.). Didn't we decide that the last History line should reference Defect Item 90 rather than 127 (itself)? 127 N Schonfelder I copy the item from Janice's recent email ballot. I am strongly opposed to this interpretation. It gratuitously complicates the users management of names to no useful gain. A module name may well be global but it is in a different class (or should be) to any other global or local name. The module name enters the program only as a module name on a USE statement. It can occur in no other context. It cannot be confused with any other use of the same name in any other context. I can see that it might cause difficulties if a module name and another global name were the same (module and main program names the same might cause difficulties for some loaders) but I cannot for the life of me see any purpose in defining module names to pollute the local name space. 127 Y Shepherd Whenever possible (ie when someone such as me notices otherwise) quotes from the standard should be indented and surrounded in quotes. This was the decision that Dick W. and I came to when the issue was last discussed. 127 Y Zongaro In the last paragraph under "Discussion for Answer 1:" change "" to "". --------------------- 000148 RANDOM_SEED, RANDOM_NUMBER 148 Y Bierman The sample code fragment in Question (2) will not execute on all processors as it stands, as it assumes that the required size of the seed is no greater than 2. Replace the declaration of SEED with the following three lines: INTEGER, ALLOCATABLE :: SEED(:) CALL RANDOM_SEED(SIZE=K) ALLOCATE(SEED(1:K)) In addition, the answer specifies what happens when a call is made to RANDOM_SEED with a PUT argument which had been returned by an earlier call to RANDOM_SEED as the GET argument. It does not specify the behaviour of calls to RANDOM_SEED with PUT arguments which were not returned as earlier GET arguments. To clarify, the answer does not specify that X1=X2 after the following sequence INTEGER, ALLOCATABLE :: SEED(:) CALL RANDOM_SEED(SIZE=K) ALLOCATE(SEED(1:K)) SEED = 123 CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X2) nor does it explicitly say that X1 need not equal X2. Although the question did not ask about the behaviour in this situation, it would be worthwhile framing the response and edits so that such situations are taken care of as well. 148 Y Bleikamp Although Henry's comment about the size of the seed is correct, I don't think this is really a flaw in the answer; therefore, I suggest an editorial change to the answer, along the lines of (to be inserted by the 006 editor wherever she wishes): "Note that this program is standard conforming for a given processor only if that processor returns the value '2' or '1' in the SIZE argument when RANDOM_SEED is called." I would still vote yes without this editorial change. 148 N Hendrickson As stated in previous e-mail, I do not think it is correct to have RANDOM_SEED with no argument be processor dependent to the extent that the sequence changes from time to time. There is no way a program can use this feature. We should define the concept of a default sequence and say that RANDOM_SEED with no argument produces the default processor dependent sequence. 148 N Hirchert I oppose this item for two reasons: 1. The new requirements it imposes have the potential to cost orders of magnitude on many high performance processors. 2. The set of expectations it documents are incomplete. The problem with making these expectations requirements is that they have the effect of forcing calls to RANDOM_NUMBER to be executed in a specific order, even when the programmer has no interest in which variable gets which random number. This can be an impediment to vectorization and/or parallelization, potentially resulting in orders of magnitude performance reductions. (I agree that even on such processors, some programmers will be willing to trade performance for reproducibility to facilitate debugging or comparison of alternative analyses of the same problem, so such processors could reasonably provide a second random number generator that meets our expectations. I would suggest, however, that since there is no way to declare the peculiar property of a procedure having internal side effects but being reorderable anyway, this property is most recently attached to the intrinsic procedure, with the more conventional behavior of not allowing reordering being ascribed to the module or external procedure implementation of the random number interface. For one example of the incompleteness of this specification of our expectations, see the Shepherd/Zongaro ballot. I would be much more comfortable if we developed a complete statement of our expectations rather than doing them one at a time. 148 N Maine The edit in this item presumes that 176 passes and I disagree with 176. Specifically, the edit for 148 includes the statement "Computation of the seed from argument PUT and of argument GET from the seed is performed in a processor dependent manner." This directly contradicts the definition of GET in section 13.13.84, which says that "[The GET argument] is set by the processor to the current value of the seed." Interp 176 attempts to change that sentence. However 176 has not yet passed and a) I disagree that the sentence should be changed at all, and b) Interp 176 mangles it. 148 N Martin The text of the edit does not clarify the situation. Why bring in the argument P since it does not appear in the examples? I suggest replacing, "If the GET argument corresponding to PUT argument P ... X1 equals X2." with "However, if SEED2 is used as a PUT argument in a call to RANDOM_SEED, the subsequent sequence of pseudorandom numbers generated will be the same. For example, following execution of the statements CALL RANDOM_SEED (GET = SEED2) CALL RANDOM_NUMBER (X1) CALL RANDOM_SEED (PUT = SEED2) CALL RANDOM_NUMBER (X2) X1 equals X2." It would be a good idea to cover the cases Zongaro mentions as well. 000148 N Reid I do not disagree with the intent, but the edit needs attention in my opinion. Here is my suggestion, with change bars. EDIT: In section 13.13.84 add the following text [228:13+] "The pseudorandom number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Computation of the seed from argument PUT and of argument GET from the seed is performed in a processor dependent | manner. The value specified by PUT need not be the same as the | value returned by GET in an immediately subsequent reference to | RANDOM_SEED. For example, following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) | SEED1 need not equal SEED2. When the values differ, the use of | either value as the PUT argument in a subsequent call to RANDOM_SEED | will result in the same sequence of pseudorandom numbers being | generated. For example, after execution of the statements | CALL RANDOM_SEED(PUT=SEED1) | CALL RANDOM_SEED(GET=SEED2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." 148 N Zongaro The sample code fragment in Question (2) will not execute on all processors as it stands, as it assumes that the required size of the seed is no greater than 2. Replace the declaration of SEED with the following three lines: INTEGER, ALLOCATABLE :: SEED(:) CALL RANDOM_SEED(SIZE=K) ALLOCATE(SEED(1:K)) In addition, the answer specifies what happens when a call is made to RANDOM_SEED with a PUT argument which had been returned by an earlier call to RANDOM_SEED as the GET argument. It does not specify the behaviour of calls to RANDOM_SEED with PUT arguments which were not returned as earlier GET arguments. To clarify, the answer does not specify that X1=X2 after the following sequence INTEGER, ALLOCATABLE :: SEED(:) CALL RANDOM_SEED(SIZE=K) ALLOCATE(SEED(1:K)) SEED = 123 CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X2) nor does it explicitly say that X1 need not equal X2. Although the question did not ask about the behaviour in this situation, it would be worthwhile framing the response and edits so that such situations are taken care of as well. --------------------- 000158 Leftmost (on a line) negative integer 158 N Bierman While I can easily follow our logic in this answer, I still don't see this as a desirable outcome. We ought to have come up with a way to permit the assignment. This sort of asymmetry is what drives users to distraction, and it doesn't make the language particularly easier to document, implement or support. I lost this argument during committee debate, and I don't expect to win it now ;> 158 Y Hirchert While I have some sympathy for the concerns about the inconvenience this causes, I do not believe that processors should be _required_ to "stand on their heads" to deal with intermediate positive results that are out of range on the possibility that they may be later negated back into range. 158 N Martin There should be some reference to the integer representation model which is symmetric. The explanation I have heard before is that the model is imposed on a processor, and if the processor can represent values that fall outside the model, they must (shall) not appear in a portable (standard-conforming) program. Clearly, the language syntax does not permit nonsymmetric values. Is this not enough? 158 N Terpstra I agree with Keith that it would be desirable to find a way to permit the assignment. 158 N Zongaro As others have pointed out, the last paragraph of the answer to this defect item brings into question what it means for a program to be standard-conforming. Is a program standard- conforming only in relation to a particular processor? This answer implies that. If that was really what was intended by the committee, then that's fine. If that's not what was intended (or it's not known what was intended), I'd like to recommend the following change to the last paragraph of the answer. Change "A program is not standard-conforming if it contains" to "A program must not contain". Either way, the definition of standard-conforming program could probably stand some clarification in future revisions. --------------------- 000173 Definition of elemental intrinsic subroutine 173 Y Bierman The second sentence of the recommended edit describes a restriction on intrinsic subroutine references in general. As such, it does not belong in section 13.2.2, which is entitled, "Elemental intrinsic subroutine arguments". I'd like to recommend the following edits instead: "EDIT: Add the following sentence to the end of section 13.2.2 [183:35]: "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM arguments may be the same variable." Add the following sentence to the end of section 13.9 [187:39]: "Except as noted in 13.2.2, the actual arguments in a reference to an intrinsic subroutine must satisfy the restrictions of 12.5.2.9." If this suggestion is rejected, in the first sentence of the edits section, "sentence" should be "sentences". 173 Y Bleikamp (from Henry's comments, an editorial change) In the first sentence of the edits section, "sentence" should be "sentences". 173 Ywc Hendrickson I agree with the Zongaro comment 173 Y Hirchert I like the style of the Shepherd/Zongaro alternative edit but did not feel strongly enough about it to vote against the edit passed at the meeting. 173 N Martin In Question 2, the first word should be 'Alternatively" In the Discussion, delete the last word, "also". I prefer the edits suggested by Zongaro. 0173 Y Rolison I approve the direction of the response and approve of the first sentence of the edit, but I fail to see how 12.5.2.9 relates at all to expectations on *actual* arguments to *intrinsic* procedures. Note that 12.5.2.9 is discussing how and when one can affect the value or definition of an actual argument once the called procedure has been invoked. For example, No action may be taken that affects the value or availability of the entity [the associated actual argument] or any part of it, except through the dummy argument. Well, once the user has invoked an intrinsic procedure, I know of no way the user can then affect the associated actual argument. The only activity taking place is the execution of the intrinsic procedure. I think the wrong section has been referenced. 173 N Zongaro The second sentence of the recommended edit describes a restriction on intrinsic subroutine references in general. As such, it does not belong in section 13.2.2, which is entitled, "Elemental intrinsic subroutine arguments". I'd like to recommend the following edits instead: "EDIT: Add the following sentence to the end of section 13.2.2 [183:35]: "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM arguments may be the same variable." Add the following sentence to the end of section 13.9 [187:39]: "Except as noted in 13.2.2, the actual arguments in a reference to an intrinsic subroutine must satisfy the restrictions of 12.5.2.9." If this suggestion is rejected, in the first sentence of the edits section, "sentence" should be "sentences". --------------------- 000176 Definition of RANDOM_SEED 176 Y Bleikamp I like Janice's editorial change for 176 (change "set to" to "assigned"). 176 Ywc Hendrickson I agree with the Sheperd comment. 176 N Hirchert I am uncomfortable with this business about TRANSFER semantics. From my perspective, a seed characterizes or can be used to generate the internal state of the random number generator, but there should be no requirement that every bit of the internal state be represented in the seed. I could even imagine implementations in which an attempt to GET the seed would result in the internal state being "tweaked" into one that could be generated from a seed value (so that seed could be returned and have the expected semantics of reproducibility). 176 N Maine I completely disagree that any change at all is needed for this interpretation. Even if a change is needed, this version botches it. The whole question is meaningless because it is based on a misunderstanding of the definition of the seed. Specifically, the question is centered around the issue of what happens when the seed might not be an array of integers. However, the standard specifies that the seed is *ALWAYS* an array of integers, so the question is moot. Note the definition of the GET argument in section 13.13.84. It says that the GET argument "is set by the processor to the current value of the seed." This leaves no leeway for "processor-dependent computations". Nor is any such leeway required. The processor may choose to maintain internal data structures of any type or complexity. These structures may have the same "physical representation" as the seed. However, it is the integer array, not the other data structure, which is defined by the standard to be the seed. The details of how this integer array is used internally are not specified by the standard and do not need to be. All possible integer array values might not be suitable seed values for a particular processor, so the standard allows processor-dependent computations to be performed on the PUT argument. This is already in f90 and needs no change. An edit to clarify it would be acceptable. No such computations are necessary for the GET argument. Finally, even if the committee disagrees with my position that no computations are necessary for the GET argument, the specific edit proposed botches it by saying "It is set to the current value of the seed in a processor dependent manner." This sounds like an attempt at compromise that came out nonsensical. If the argument is "set to the current value of the seed" then there is no leeway for processor dependence. The seed either has a value that is an array of integers or it doesn't. If it does have such a value, then the processor dependence phrase is superfluous. If it doesn't have such a value, then there is no way, processor-dependent or not, for the processor to set the argument to this non-existant value. Presumably it is intended that the processor would set the argument to some other value computed in a processor-dependent way. But that is not what this sentence says. This edit doesn't fix an inconsistency; it introduces one. Quite a few more words would be necessary to define what is going on here. By the time you have them all correct, I think you'd find that you had defined two items. One of them (the value actually returned by GET) would be what is now called the seed, but you'd presumably propose to call something else. The other would be some mysterious internal object that would then be called the seed. This internal object is actually irrelevant to the definition of the semantics of the interface. I think that the f90 standard as it already stands is wise to have not even brought up such an irrelevancy. The whole question arises from confusing this mysterious internal object with the seed. Perhaps some people are focussing too much on implementation concepts here. An implementation might well have an internal object that it calls the seed. There is no need for the standard specification of the interface to even mention such an implementation detail. 176 Y Martin In QUESTION 1, change "Alternately" to "Alternatively" In EDIT 2, change "set to" to "assigned" 176 Y Shepherd Part of the concern raised in the question is the double meaning of the word "set". Let's fix that problem too. In the 2nd edit change 'set to' to 'assigned' --------------------- 000186 Allowed values of POSITION= and STATUS= specifiers when changing BLANK= 186 Y Bleikamp (from Henry's comments, an editorial change) A closing quote is missing at the end of the second edit. GRAHAM NOTED (in the previous letter ballot on 000186): 2. Edit 2 refers to the status of a file being "SCRATCH" However there is no such status defined by the standard. Section 9.3.4.2 does not specify what the status of a file opened with STATUS="SCRATCH" is. I suggest that this section be amended to introduce such a status so that edit 2 can refer to it. The /interp subgroup addressed Graham's other concerns, but not this one. I think that was appropriate, and that there is NO NEED to define what the status of a file opened with STATUS SCRATCH is. The only statuses mentioned in 9.3.4.2 have to do with the status after the open, when the status is different than what the user specified (new->old, replace->old, ...). 186 Y Hirchert I am slightly nervous about the handling of POSITION=. If a reOPEN specified POSITION='APPEND', would there be any expectation that a processor would have to determine whether the file was positioned at the end of the file in order to know whether to simply process the reOPEN or return a nonzero IOSTAT value? This could a serious problem on devices where the only way to recognize end-of-file is to attempt to read past it (e.g., the handling of the terminal under Unix and many other operating systems). I would be much more comfortable if POSITION in a reOPEN were required to be 'ASIS', just as STATUS in a reOPEN is required to be 'OLD'. I am not certain enough about my discomfort with this issue to vote NO on this item, but if my comments make anyone else uncomfortable, I would suggest that this item be pulled for reexamination. 186 Y Martin In ANSWER 2, 2nd sentence, delete "to say" In ANSWER 5, 7th paragraph, change "when unit" to "when a unit" 0186 Y Rolison It could use some minor editorial clean-ups. For example: QUESTION 1:What is a bit jammed together. I believe the heading should simply be "QUESTION" and individual questions under this heading should be numbered, as in QUESTION: 1. What... and similarly "ANSWER 1:The" would be better as ANSWER: 1. The... Another nit: In the new text for the first edit, a quote is missing following the last period (which means you might want to change the quotes around OLD to apostrophes). The same is true for the second edit and SCRATCH. Why does the first edit put quotes around OLD but the third edit does not? The phraseology looks the same to me. 186 Y Zongaro A closing quote is missing at the end of the second edit. --------------------- 000193 Pointer actual arguments with the OPTIONAL attribute 193 Ywc Hendrickson I agree with the Sheperd comment. 0193 N Rolison This program does NOT violate any rules of the standard. The rule about a disassociated pointer only being passed to a pointer dummy argument is irrelevant in this case because nothing is being passed from INNER to SUB. Yes, the *syntax* indicates that an argument is being passed but at run-time nothing gets passed; there was no argument passed into INNER, therefore there is no argument passed to SUB at run time, therefore the rule is irrelevant. In either case (whether argument PARG was present or not), no harm comes to the program. That is, if it is present, it gets dereferenced and the the target is happily passed on. If it is not present, SUB can't do anything with it anyway. 193 Y Shepherd Add the keywords: argument - optional, POINTER attribute