J3 paper J3/00-254 Date: 31-July-2000 To: J3 Members From: interp/Stan Whitlock Subj: Results of the F95 interp letter ballot #2 Here are the results of J3 letter ballot #2 on Fortran 95 interpretations that closed on 28-Jul-2000. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep 1 3 4 5 12 29 66 Rich Bleikamp Y Y Y Y Y Y Y Malcolm Cohen Y Y N C Y N Y Craig Dedo Y Y Y Y Y C Y Dick Hendrickson Y Y Y Y Y Y Y Kurt Hirchert Y Y C C Y N C Larry Meadows Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Mike Ross Y Y Y Y Y Y Y Jeanne Martin for BSmith Y Y Y N Y N Y Van Snyder Y Y Y Y Y Y Y Jon Steidel Y Y C C Y N N Matthijs van Waveren Y Y Y C Y C Y Tony Warnock Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Henry Zongaro Y Y N N Y N N where Y means "yes" C "yes with comment" N "no with comment" The comments are attached below in the same order as the table above. The summary of results is as follows: P = passed 1 3 4 5 12 29 66 C = passed as amended F = further consideration P P F C P F F The interps marked "P" can be considered by WG5 at John Reid's convenience. Interp 000005 is marked "C" because I believe that John Reid's proposed fix {in e-mail SC22WG5.1881 dated 11-Jul-2000} of Henry's complaint plus adding Henry's 1-argument examples satisfies the NO votes on 000005. I have attached the new 000005 to this mail so 000005 is ready for WG5. The interps marked "F" will be reconsidered at or before J3 meeting #154 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** Status Number Title 000001 Visibility of a data object with statement scope 000003 Ability to overload the character operator // 000004 Value returned by MAXVAL/MINVAL Malcolm's NO comment on 000004: I agree with Henry's comments on this one. At the very least the answer should indicate that a return value of -INF/+INF is only acceptable if that value is treated in a standard-conforming way by other Fortran facilities (e.g. i/o, EXPONENT, SCALE, ...). However, since to do this would essentially be to treat INF as not infinity but a specific big number (quite against the IEEE intentions), a better response is not to allow an INF return value until the standard has been altered to cope with such values - e.g. by specifying i/o formats, return values from EXPONENT, FRACTION, SCALE, etc. Kurt's YES comment on 000004: The key property is that the value returned by a reduction operation on a zero-size array be an identity for the underlying binary operator. -HUGE would not be an identity for MAX if there are non-model values less than -HUGE. If my memory isn't playing tricks on me, there are two different ways IEEE can be asked to handle infinities: 1. Both infinity and zero can be signed, and -infinity tests less than or equal to everything but NaNs, so it is an appropriate value to return from MAXVAL. 2. Neither infinity nor zero is signed, and infinity is not ordered relative to finite values (because it could, in effect, be either -infinity or +infinity). In this case, infinity would _not_ be an appropriate value to return from MAXVAL or MINVAL. I don't think I've ever seen a machine running in the latter mode, so maybe we don't need to mention it. Jon's {et al} YES comment on 000004: Perhaps a better response for question 2 would be: A program can determine the implementation representation of the largest magnitude by evaluating the MAXVAL and MINVAL functions with a zero-sized array argument. These results can be used as comparison values in the program. integer,dimension(1:-1) :: int_zero_sized_array integer :: int_max_eval,int_min_eval real,dimension(1:-1) :: real_zero_sized_array real :: real_max_eval,real_min_eval real(kind(1.d0)),dimension(1:-1) :: dp_zero_sized_array real(kind(1.d0)) :: dp_max_eval,dp_min_eval int_max_eval = maxval (int_zero_sized_array) int_min_eval = minval (int_zero_sized_array) real_max_eval = maxval (real_zero_sized_array) real_min_eval = minval (real_zero_sized_array) dp_max_eval = maxval (dp_zero_sized_array) dp_min_eval = minval (dp_zero_sized_array) Henry's {et al} NO comment on 000004: After considering this response and the e-mail discussion that surrounded it (particularly, Malcolm's e-mail SC22WG5.1766), we felt that it will do a disservice to state simply that "IEEE -inf. . . may be returned on a machine that supports the IEEE standard." We believe most users are likely to read the response to this interpretation and expect any Fortran processor implemented on hardware that supports IEEE inf and -inf to return inf and -inf as the results of MINVAL and MAXVAL, respectively, when applied to zero-sized arrays. We realize that the words "may be" were intended to avoid just such an issue arising, but we feel that further qualification is required. We agree that MAXVAL and MINVAL, when applied to a zero-sized array, could return values that are outside of the model. However, it's our belief that if a processor returns such a value, it must be a genuine real value of the processor; the processor would have to ensure that it handles the value in a manner that is consistent with the rules of the standard. We don't believe any processor does that today with IEEE inf and -inf. 000005 Value returned by SELECTED_REAL_KIND Malcolm's YES comment on 000005: The edit currently reads: Page 266, Clause 13.14.95, lines 11-14 (266: 26-29). Replace 'the result is -1 ... is supported.' by 'the result is -1 if the processor does not support a real data type with a precision greater than or equal to P but does support a real data type with an exponent range greater than or equal to R, -2 if the processor does not support a real data type with an exponent range greater than or equal to R but does support a real data type with a precision greater than or equal to P, -3 if the processor supports no real data type with either of these properties, and -4 if the processor supports real data types for each separately but not together.' It would be made less ambiguous (qua Henry's comments) by inserting after "-4 if" the words "both P and R are present and". Kurt's YES comment on 000005: If I remember correctly, this same issue was brought up during the original adoption of SELECTED_REAL_KIND, and at that time the subgroup making the proposal claimed that there was no need for an additional value to cover this case. (I think they argued that this situation was sufficiently unusual that it was not necessary to provide for it specially, and that if it occurred, the processor could reasonably return either -1 or -2 to indicate that it could provide a type that fulfilled one of the requirements but could not provide one that met both.) If we (or a vendor extension) were to provide a third property to be used in selecting a REAL kind, the "obvious" extension to SELECTED_REAL_KIND would have been for -4 to indicate that the new X factor could not be satisfied, -5 that the precision and X factor could not be satisfied, -6 that the exponent range and X factor could not be satisfied, and -7 that all three could not be satisfied. This new meaning for -4 is incompatible with that "obvious" extension. All this makes me uncomfortable about this interpretation, but not sufficiently to justify a no vote. Jeanne's NO comment on 000005: The suggested replacement text is overly specific, but still fails to cover cases where one of the optional arguments is omitted. Also adding a new return value (-4) is not upwardly compatible with existing processors. It would be simpler to add the phrase, "or both are supported but not together" before the period at [266:29]. Jon's {et al} YES comment on 000005: We agree with John Reid's comments. Matthijs' {et al} YES comment on 000005: The proposed edits correctly deal with the cases in which both the P and R arguments of the SELECTED_REAL_KIND intrinsic are specified. Unfortunately, the case in which only one of the two arguments is specified is not covered anymore. We propose to extend the edit as follows: EDITS: Page 266, Clause 13.14.95, lines 11-14 (266: 26-29). Replace 'the result is -1 ... is supported.' by 'the result is as follows: Case(i): If both P and R are present, the result is -1 if the processor does not support a real data type with a precision greater than or equal to P but does support a real data type with an exponent range greater than or equal to R, -2 if the processor does not support a real data type with an exponent range greater than or equal to R but does support a real data type with a precision greater than or equal to P, -3 if the processor supports no real data type with either of these properties, and -4 if the processor supports real data types for each separately but not together. Case(ii): If only P is present, the result is -1 if the processor does not support a real data type with a precision greater than or equal to P. Case(iii): If only R is present, the result is -2 if the processor does not support a real data type with an exponent range greater than or equal to R.' Henry's {et al} NO comment on 000005: The edits proposed in the response to interpretation 000005 correctly deal with the cases in which both the P and R arguments of the SELECTED_REAL_KIND intrinsic are specified. However, they inadvertently ignore the case in which only one of the two arguments is specified. So, using the example precision and range values from the question, it's not clear from the revised text what should be the result of a reference of either of the following forms: SELECTED_REAL_KIND(P=32) SELECTED_REAL_KIND(R=308) The existing wording in the standard makes it clear that the result of the first reference should be -1, and the result of the second should be -2. John Reid's comment on 000005 in mail dated 11-JUL-2000: Henry Zongaro points out that the proposed rewording does not properly allow for the case with only a single argument. Since I proposed this text, I thought I would prepare a fix. I think any reader will understand the intention, but we might as well correct it. Actually, the first part of the sentence (266:23-25) can be viewed as broken when one argument is missing. A simple way to correct both these is to add at line 23: If P or R is absent, the result value is as would have been obtained with the argument present with the value 0.' 000012 Evaluation of Intrinsic Procedures 000029 Association of a pointer actual argument with a\ dummy argument Craig's YES comment on 000029: I agree with Kurt Hirchert's comments on this interp, but I do not believe that the difficulties he mentions should stop approval. Proposed new title: User-defined assignment for derived-type components. Whether we should use intrinsic assignment always in a DATA statement is an issue that should be addressed in a separate interp. The DATA statement case has its own set of technical issues and is substantially different from the case of an executable assignment statement. Malcolm's No comment on 000029: I concur with Kurt. The title should be something like "Defined assignment and nested derived types." The edits are hopelessly broken. Back to the drawing board. Kurt's NO comment on 000029: 1. This title bears no resemblance to the actual subject of the interpretation. It should be changed. 2. I am concerned that this interpretation is incomplete. Intrinsic assignment is used for two purposes: a. It is the meaning given to an assignment statement in the absence of an applicable defined assignment. b. It is used for the DATA statement and initialization in a type statement, even if there is an applicable defined assignment. I believe that in case (a), we want this modification to intrinsic assignment, but that in case (b) we really want to retain the F90 behavior, so user procedures don't have to be called for static initialization. Jeanne's NO comment on 000029: The title of M16 and 97-197 is "Derived-Type Assignment Fix". I agree with Kurt that user precedures should not be called for static initialization. - Needs more work. Jon's {et al} NO comment on 000029: We agree with comments from Kurt, Jeanne, Henry, and Malcolm's ballots; user procedures should not be called for static initialization. Matthijs' {et al} YES comment on 000029: We comment that allowing user procedures to be called for static initialization is an extension of the functionality of Fortran 95, and will introduce changes in Fortran processors. The committee might want to rethink, whether that is the purpose of the edits. Henry's {et al} NO comment on 000029: As others have noted, the title doesn't capture the essence of the request. In 2.2.3, 12.4.3 and in the glossary there appear definitions of the word "reference" as it applies to subroutines. They indicate that a reference to a subroutine occurs as a result of a CALL statement or a defined assignment statement. This change introduces a third place in which a reference to a subroutine can occur - namely, in a defined assignment that results from a derived-type intrinsic assignment statement. We also concur with Kurt's comments on this response. The standard uses the term "intrinsic assignment" to describe how type conversion is handled for explicit initialization, default initialization and structure constructors; defined assignment of components has no place there. We'd like to recommend that a new term be used to describe assignment of an expression of a derived type to an object of the same type, when intrinsic assignment might be used for some components and defined assignment for others. Use of the word "intrinsic" to cover this case seems to be confusing. 000066 Errors in processing data transfer statements Kurt's Yes comment on 000066: I agree with the basic thrust of this interpretation, but I still am concerned about the case of an error whose exact location cannot be determined. For example, if a CRC or parity check fails, we know something is wrong with the record, but we do not know exactly what. Is the processor required to buffer such input so the CRC or parity check can be performed _before_ any data is transferred? Jon's {et al} NO comment on 000066: We agree with Henry's comments. The standard is intentionally vague here and that no edits should be applied. Henry's {et al} NO comment on 000066: We agree with Kurt that there might still be cases in which a processor cannot detect an error that occurs during processing of a data transfer list at the point at which the error occurs. ********************************************************************** NUMBER: 000005 TITLE: Value returned by SELECTED_REAL_KIND KEYWORDS: SELECTED_REAL_KIND DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: The SELECTED_REAL_KIND intrinsic function does not appear to cover one specific case for real data types. Consider the following precisions and ranges for a particular model: KIND TYPE PRECISION RANGE 4 6 37 8 15 307 16 31 291 A test case for a system with this model is: PRINT *, 'selrealkind(31,291) = ', SELECTED_REAL_KIND(P=31,R=291) PRINT *, 'selrealkind(31,292) = ', SELECTED_REAL_KIND(P=31,R=292) PRINT *, 'selrealkind(32,291) = ', SELECTED_REAL_KIND(P=32,R=291) PRINT *, 'selrealkind(32,292) = ', SELECTED_REAL_KIND(P=32,R=292) END The Result Value section of the description of SELECTED_REAL_KIND clearly describes the result value when the values of P and R are within the ranges specified for the given implementation of the real data type model. It further describes the values to be returned by SELECTED_REAL_KIND when a value of P or R is not within the range of model numbers specified by the implementation. From the text in the Result Value section, the following may be determined: * The reference to SELECTED_REAL_KIND(P=31,R=291) (first PRINT line) should return the (kind type parameter) value 16. * The third and fourth SELECTED_REAL_KIND references should return -1 since the PRECISION argument is outside the set of allowed precision values. However, the value returned by the second reference to SELECTED_REAL_KIND is unknown since it does not appear to be covered by the wording of the Result Value paragraph of section 13.14.95. 1. What should the processor return for the value of the SELECTED_REAL_KIND intrinsic function when it does not have a single data type that satisfies both the P and R values? 2. In particular, given the precision and range values shown above, what should the processor return for the last three invocations of the SELECTED_REAL_KIND intrinsic function? ANSWER: The intention is that the value -1 be returned if the range can be supported but the precision cannot, the value -2 be returned if the precision can be supported but the range cannot, and the value -3 be returned if neither the precision nor the range can be supported. Provision needs to be made for the case where each can be supported, but not in combination. With the edit below, the returned values for the four invocations will be 16, -4, -1, -1. In addition, using the model above, these test cases: PRINT *, 'selrealkind(32) = ', SELECTED_REAL_KIND(P=32) PRINT *, 'selrealkind(r=308) = ', SELECTED_REAL_KIND(R=308) the returned values for the two invocations will be -1, -2. EDITS: Page 266, Clause 13.14.95, line 8 (266: 23). After , add 'If P or R is absent, the result value is as would have been obtained with the argument present with the value 0.' Page 266, Clause 13.14.95, lines 11-14 (266: 26-29). Replace 'the result is -1 ... is supported.' by 'the result is -1 if the processor does not support a real data type with a precision greater than or equal to P but does support a real data type with an exponent range greater than or equal to R, -2 if the processor does not support a real data type with an exponent range greater than or equal to R but does support a real data type with a precision greater than or equal to P, -3 if the processor supports no real data type with either of these properties, and -4 if the processor supports real data types for each separately but not together.' SUBMITTED BY: Larry Rolison / Joanne Brixius HISTORY: 97-241 m143 submitted 00-161 m153 Passed unanimously as amended 00-Aug m153 Passed by J3 letter ballot as amended ----------------------------------------------------------------------