J3/05-167 Date: 5-Mar-2005 To: J3 Members From: interp/Stan Whitlock Subj: J3 Fortran interp letter ballot #11 - due 31-Mar-2005 Enclosed in the eleventh letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 25 Fortran 2003 interpretations are currently "Passed by J3 meeting" after J3 meeting #171. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0028 Commas in complex namelist output --- --- F03/0030 IEEE divide by zero --- --- F03/0031 IEEE invalid --- --- F03/0032 Sign bit of IEEE NaN --- --- F03/0033 IEEE_VALUE() --- --- F03/0034 IEEE_LOGB() --- --- F03/0035 IEEE_NEXT_AFTER() --- --- F03/0036 IEEE_REM() --- --- F03/0037 IEEE_RINT() --- --- F03/0038 IEEE_SCALB() --- --- F03/0039 HYPOT() --- --- F03/0040 2.0+2.0 and IEEE --- --- F03/0041 IEEE halting and exceptions --- --- F03/0043 Passed-object arguments and procedure pointer components --- --- F03/0044 Implicit interfaces and conflicting references --- --- F03/0045 Finalization and assumed- arguments with INTENT(OUT) --- --- F03/0046 Unlimited polymorphic pointers in common blocks --- --- F03/0047 Polymorphic arguments to intrinsic procedures --- --- F03/0048 Control edit descriptors in UDDTIO --- --- F03/0049 Separators in list-directed output involving UDDTIO --- --- F03/0051 Repeat specifiers and UDDTIO --- --- F03/0052 ADVANCE= specifier in child data transfer statements --- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR --- --- F03/0054 Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT --- --- F03/0055 Denormal inputs to SPACING and RRSPACING The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PST, Thursday, 31-Mar-2005, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The 7th paragraph in 10.9.2 for list directed output says: "Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA." There are similar words in most other places where complex formatting is described. The second paragraph of 10.10.1.3 Namelist group object list items says: "When the next effective item is of type complex, the input form of the input value consists of a left parenthesis followed by an ordered pair of numeric input fields separated by a comma and followed by a right parenthesis. " Other places correctly describe namelist complex output as having a separator, either a comma or a semicolon, depending on the decimal edit mode. Should the namelist version be reworded to say "comma or semicolon"? ANSWER: Yes. Edits are supplied to correct this oversight. In addition, a similar issue exists for list directed input of undelimited character values and namelist output of character values. EDITS: All edits refer to 04-007. [240:13] Replace "comma" with "comma, or semicolon if the decimal edit mode is decimal," [244:29] Replace "comma" with "separator". [244:30] Before "The first", add the following sentence: The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA. [244:32] Replace "comma" with "separator". [244:33] Replace "comma" with "separator". [245:4] after "comma," insert " semicolon," SUBMITTED BY: Dick Hendrickson HISTORY: 04-409 m170 Submitted 04-409r1 m170 Passed by J3 meeting 05-146 m171 Failed interp letter ballot #10 05-164 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEEE-754). The definitions in 14.2 were intended to describe IEEE exceptions with sufficient latitude to allow use on near-IEEE and non-IEEE machines. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with the IEEE International Standard. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with the IEEE standard, because this exception is not raised for operations on infinite operands. Edits are provided to fix these inconsistencies. EDITS: Page and line numbers refer to 04-007. [365:13-15] Clause 14.2, lines 3 and 5. After "assignment" add "with finite operands", twice. [365:18] Clause 14.2, line 8. Change "nonzero numerator" to "finite nonzero numerator". SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 Submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0031 TITLE: IEEE invalid KEYWORDS: IEEE-754, invalid exception DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What exceptions (if any) are raised by the following: infinity + (-infinity) infinity - infinity 0.0 * infinity infinity / infinity 0.0 / 0.0 Fortran 2003 is silent on these expressions. IEEE-754 defines (in 7.1) those as invalid. ANSWER: The Fortran Standard and Technical Report ISO/IEC TR 15580 were written to supplement the IEEE International Standard and to allow for systems that do not fully support it. That the IEEE International Standard is a normative reference is made clear in 1.9. The questions related to infinity are answered by the third paragraph of 14.8, which states "The inquiry function IEEE_SUPPORT_INF is provided to inquire whether the processor supports IEEE infinities. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard." The expression 0.0 / 0.0 is defined as invalid by the IEEE International Standard and therefore causes the exception IEEE_INVALID to occur. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-110 m171 Submitted 05-110r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0032 TITLE: Sign bit of IEEE NaN KEYWORDS: IEEE-754, NaN, sign bit, negative DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Do IEEE-754 NaNs have a sign bit? Can they be negative? Does a sign bit imply a value can be either positive or negative? Fortran 2003 in 14.10.2 (IEEE_COPY_SIGN) says that NaNs have a sign bit. But, 14.10.10 (IEEE_IS_NEGATIVE) says NaNs are not negative. This appears to be a contradiction between two parts of Fortran 2003. ANSWER: The representation of a NaN has a sign bit, and this is what is referred to in 14.10.2. However, that bit is not interpreted as a sign (see IEEE standard, 6.3 "This standard does not interpret the sign of a NaN"). Thus 14.10.10 correctly says that a NaN is never negative. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-111 m171 Submitted 05-111r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0033 TITLE: IEEE_VALUE() KEYWORDS: IEEE-754, IEEE_VALUE DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What does "Generate an IEEE value" in 14.9.2 mean? Fortran 2003 in 14.9.2 has: "Generate an IEEE value" without any explanation of what that means, nor any indication that it is defined elsewhere. ANSWER: 14.9 contains tables of procedures with a short description of each, modeled on 13.5. Each procedure is specified in 14.10 and the reader should have no difficulty in finding its specification there. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-112 m171 Submitted 05-112r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0034 TITLE: IEEE_LOGB() KEYWORDS: IEEE-754, logb() DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: What is logb(denormal)? Is it of the hardware representation, or is it as if the hardware had an unbounded exponent range? What is logb(NaN)? logb(-INF)? logb(+INF)? logb() should be defined as if the hardware representation had an unbounded exponent range. logb(NaN) should be the same NaN; shall be a NaN. logb(-INF) shall be +INF logb(+INF) shall be +INF ANSWER: The first paragraph of 14.8 states "Complete conformance with the IEEE International Standard is not required, but ... the functions copysign, scalb, logb, nextafter, rem, and unordered shall be provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB, IEEE_NEXT_AFTER, IEEE_REM, and IEEE_UNORDERED." Case (i) of 14.10.12 correctly specifies that if the value of X is denormal, its unbiased exponent is returned; however, the note there is wrong in this case. An edit is supplied. For consistency with the IEEE International Standard, an edit is also supplied for the case where X is infinite. EDITS: Page and line numbers refer to 04-007. [376:15]. Subclause 14.10.12, Result Value, line 2. After "Note:" add "if X is normal,". [376:17+]. Subclause 14.10.12, Result Value. Add extra case: "Case (iii) If IEEE_SUPPORT_INF(X) is true and X is infinite, the result is +infinity." . SUBMITTED BY: Fred Tydeman HISTORY: 05-113 m171 Submitted 05-113r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0035 TITLE: IEEE_NEXT_AFTER() KEYWORDS: IEEE-754, nextafter() DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What is NEXT_AFTER(+0.0,-0.0)? NEXT_AFTER(-0.0,+0.0)? What is NEXT_AFTER(X,Y) if X and/or Y is NaN? C99 and IEEE-754R (the revision of IEEE-754 now in progress) define NEXT_AFTER(X,Y) as Y (not X) when X == Y. NEXT_AFTER(X,Y) when both X and Y are NaN shall be a NaN, and should be one of NaN arguments. NEXT_AFTER(X,Y) when one of X and Y is a NaN shall be a NaN, and should the NaN argument. ANSWER: The first paragraph of 14.8 states "Complete conformance with the IEEE International Standard is not required, but ... the functions copysign, scalb, logb, nextafter, rem, and unordered shall be provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB, IEEE_NEXT_AFTER, IEEE_REM, and IEEE_UNORDERED." For NEXT_AFTER(X,Y) with X == Y == 0, the result is X, see 14.10.13, Case (i). This is the recommendation of the IEEE International Standard. The current draft revision of that Standard uses the definition copysign(x,y) in this case. We will reconsider the Fortran definition of NEXT_AFTER if a revised IEEE Standard is adopted with this change present. The case of NEXT_AFTER(X,Y) when one or both of X and Y is a NaN is as defined by the IEEE International Standard, see the words from 14.8 quoted above. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-114 m171 Submitted 05-114r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0036 TITLE: IEEE_REM() KEYWORDS: IEEE-754, remainder() DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What is REM(infinity,Y)? REM(X,0.0)? What is REM(X,Y) if X and/or Y is NaN? IEEE-754 requires (in 7.1) both REM(infinity,Y) and REM(X,0.0) shall be a NaN and raise invalid. REM(X,Y) when both X and Y are NaN shall be a NaN, and should be one of the NaN arguments. REM(X,Y) when one of X and Y is a NaN shall be a NaN, and should be the NaN argument. ANSWER: The first paragraph of 14.8 states "Complete conformance with the IEEE International Standard is not required, but ... the IEEE operation rem shall be provided by the function IEEE_REM." The behaviour of IEEE_REM for the cases cited here is as defined for REM by the IEEE International Standard. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-115 m171 Submitted 05-115r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0037 TITLE: IEEE_RINT() KEYWORDS: IEEE-754, rint() DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What is RINT(+infinity)? RINT(-infinity)? RINT(NaN)? DISCUSSION: RINT(X) when X is an infinity shall be X. RINT(X) when X is a NaN shall be a NaN, and should be the NaN argument. ANSWER: The second and third paragraphs of 14.8 state "The inquiry function IEEE_SUPPORT_NAN is provided to inquire whether the processor supports IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard. The inquiry function IEEE_SUPPORT_INF is provided to inquire whether the processor supports IEEE infinities. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard. " Therefore, the behaviour of IEEE_RINT for the cases cited here is as defined by the IEEE International Standard in section 5.5. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-116 m171 Submitted 05-116r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0038 TITLE: IEEE_SCALB() KEYWORDS: IEEE-754, scalb() DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What is SCALB(NaN,Y)? DISCUSSION: SCALB(X,Y) when X is a NaN shall be a NaN, and should be the NaN argument. ANSWER: The second paragraph of 14.8 states "The inquiry function IEEE_SUPPORT_NAN is provided to inquire whether the processor supports IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard." Therefore, the behaviour of IEEE_SCALB for the case cited here is as defined for scalb by the IEEE International Standard. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-117 m171 Submitted 05-117r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0039 TITLE: HYPOT() KEYWORDS: IEEE-754, hypot() DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: What is HYPOT(NaN,infinity)? HYPOT(NaN,finite)? HYPOT(X,Y) when X and/or Y is an infinity (even if the other is a NaN) shall be +infinity. Reason: hypot(), when one of the arguments is an infinity, is +infinity independent of the value of the other argument. So, if the NaN argument is replaced by zero, any finite number, or any infinity, hypot(infinity,NaN) is still infinity. HYPOT(X,Y) when X and/or Y is a NaN (and neither is infinite) shall be a NaN, and should one of the NaN arguments. ANSWER: The HYPOT example in note 14.17 illustrates the use of the features of this section to provide reliable software that is fast in the uncomplicated case. We did not consider what would happen if one of the arguments is a NaN and have therefore edited the text slightly. DISCUSSION: In fact, if either X or Y is a NaN, the first executable statement will set HYPOT to a NaN without signaling an exception. The slower code in the IF construct will therefore not be executed and a NaN will be returned, which is consistent with the way NaNs are handled by intrinsic operators, see paragraph 3 of section 6.2 of the IEEE International Standard. EDITS: Page and line numbers refer to 04-007. [389:12]. Subclause 14.11, Note 14.17, final paragraph, line 2. Before "exception" add "overflow or underflow". [389:16+]. Subclause 14.11, Note 14.17, at the end of the final paragraph, add "This HYPOT function does not handle infinite arguments in the same way that the hypot function in the C International Standard does." SUBMITTED BY: Fred Tydeman HISTORY: 05-118 m171 Submitted 05-118r3 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0040 TITLE: 2.0+2.0 and IEEE KEYWORDS: IEEE-754, accuracy, transformation DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: For processors that use IEEE arithmetic, must 2.0+2.0 be 4.0? May x/5.0 be transformed into x*0.2? 1.4 (6) [2:4-5] has: "This standard does not specify: The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor." That has been used as the reason why 2.0+2.0 is not required to be 4.0. Section 14 [364:6-13] has: "If a scoping unit has access to IEEE_DATATYPE of IEEE_FEATURES, within the scoping unit the processor shall support IEEE arithmetic and return true from IEEE_SUPPORT_DATATYPE(X) (14.10.23) for at least one kind of real. Similarly, if IEEE_DENORMAL, IEEE_DIVIDE, IEEE_INF, IEEE_NAN, IEEE_ROUNDING, or IEEE_SQRT is accessible, within the scoping unit the processor shall support the feature and return true from the corresponding inquiry function for at least one kind of real. In the case of IEEE_ROUNDING, it shall return true for all the rounding modes IEEE_NEAREST, IEEE_TO_ZERO, IEEE_UP, and IEEE_DOWN." IEEE-754 specifies methods of rounding and computing numeric values, and in particular, requires that 2.0+2.0 be 4.0. So, does section 14 override the weasel words of 1.4(6)? If not, should something along the lines of: "The requirements of this section override 1.4(6)" be added to section 14? Using IEEE arithmetic, x/5.0 and x*0.2 are not equivalent, so the former may not be transformed into the latter. Does IEEE arithmetic override 7.1.8.3 and Note 7.18 and prohibit that transformation? If not, should something along the lines of: "The requirements of this section override 7.1.8.3" be added to section 14? ANSWER: Yes, for processors that use IEEE arithmetic, 2.0+2.0 and 4.0 have the same value. That is a requirement of the IEEE International Standard. However, your example is very simple. For a more complicated expression, the IEEE Standard does not specify whether intermediate results are kept in extended- precision registers. The words in Section 1 are applicable and give compilers the freedom to choose whether to keep intermediate results in such registers. No, section 14 does not override the weasel words of 1.4(6). As you point out, Section 7 allows x/5.0 to be evaluated as x*0.2. The results may be different on any binary computer. Section 14 tells us about the rounding that will occur once the processor has chosen which way to evaluate this. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-119 m171 Submitted 05-119r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0041 TITLE: IEEE halting and exceptions KEYWORDS: IEEE-754, trapping, exception DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: If a specific Floating-Point (FP) exception flag is raised, and then HALTING for that FP exception is enabled for the first time, does the program halt? Or, must the specific FP exception happen after the halting is enabled for the program to halt? Section 14.5 [368:1-8] does not answer the question. ANSWER: Section 14.5 states "Halting is not precise and may occur any time after the exception has occurred." It is therefore processor dependent as to when, if ever, the program halts. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-120 m171 Submitted 05-120r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0043 TITLE: Passed-object arguments and procedure pointer components KEYWORDS: DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Section 4.5.3.3 [52:5-7] of 04-007 indicates that passed-object dummy arguments are relevant for both type-bound procedures and procedure pointer components. However, section 12.4.1.1 [268:17-19] of 04-007 on the passed-object dummy argument and argument association mentions only type-bound procedures. Should procedure pointer components also be mentioned in 12.4.1.1? ANSWER: Yes. This was an omission in section 12.4.1.1. EDITS: [268:17] After "procedure" insert " or a procedure pointer component" SUBMITTED BY: Bill Long HISTORY: 05-106 m171 Submitted, passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0044 TITLE: Implicit interfaces and conflicting references KEYWORDS: implicit interface, procedure pointer, dummy procedure, procedure reference DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is the following program legal? module test_mod contains subroutine reference (proc,choice) ! Proc has implicit interface external :: proc ! Or ! procedure (), pointer :: proc logical :: choice if(choice) then call proc (1.0) ! Call with real argument else call proc (1) ! Call with integer argument end if end subroutine subroutine proc_real (x) real :: x end subroutine subroutine proc_integer (i) ! respelled from original submission ! without loss of generality integer :: i end subroutine end module program test use test_mod call reference (proc_real, .true.) call reference (proc_integer, .false.) end program 12.3.2.5 says: "The type...of dummy arguments of a procedure referenced from a scoping unit where the interface of the procedure is implicit shall be such that the actual arguments are consistent with the characteristics of the dummy arguments." We define a procedure reference in 2.5.6 as the "appearance of procedure designator, ... in a context requiring execution at that point." Are both calls to proc above references, at compile time? If both calls to proc are references then they both need to be consistent with the interface of the actual argument associated with the dummy procedure. This is not possible and the program would be illegal. However, if only the call executed counts as a reference, than the program is legal. The same question applies to both dummy procedures and procedure pointers with implicit interfaces. ANSWER: Technically, the question is ill-formed in asking whether the calls are references "at compile time". The standard does not have a notion of compile-time. The calls to proc are indeed references according to the definition in 2.5.6. This is a purely syntactic notion since a call-stmt is an example of "a context requiring execution at that point" and proc is the procedure designator in call proc(1.0) and call proc(1) 12.3.2.5 specifies a requirement, violations of which are not required to be detected at compile-time (12.3.2.5 is not a constraint). Every line of the program when it is actually executed by a standard-conforming processor uses only forms and relationships defined by the standard [2:9-10], and the program has an interpretation according to the standard. This program was intended to be standard conforming. However, the current language of 12.3.2.5 is confusing. The requirement on the type of dummy arguments must be laid on the procedure actually invoked and not on the procedure named in the procedure reference. A procedure with only an implicit interface has no nominal dummy arguments on which a requirement can be levied! (Ask yourself: what are the names of the dummy argument(s) of proc ?) Put another way, in call proc (1.0) proc is a "procedure reference" but proc_real is actually the procedure referenced. An edit is supplied to make this clearer. EDITS: In [266:8] change "referenced" to "invoked" SUBMITTED BY: Aleksandar Donev HISTORY: 05-127 m171 Submitted 05-127r3 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0045 TITLE: Finalization and assumed-size arguments with INTENT(OUT) KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i CONTAINS FINAL :: finalizeT END TYPE CONTAINS ELEMENTAL SUBROUTINE finalizeT(f) TYPE(t), INTENT(INOUT) :: f f%i = 10 END SUBROUTINE END MODULE SUBROUTINE xyz (d) USE m TYPE(t), INTENT(OUT) :: d(*) END SUBROUTINE PROGRAM foo USE m EXTERNAL xyz TYPE(t) :: a(10) = t(5) CALL xyz(a(2)) END PROGRAM 4.5.5.2 of Fortran 2003 states: When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated with an INTENT(OUT) dummy argument is finalized. For assumed-size arguments, this situation is similar to that of default initialization with INTENT(OUT). Default initialization is prohibited for INTENT(OUT), assumed-size dummy arguments by C544. A similar restriction on finalization may have been overlooked. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. An edit is supplied to correct this oversight. EDITS: All edits refer to 04-007. [80:9] Before "a type", insert "a finalizable type or". SUBMITTED BY: Rob James HISTORY: 05-136 m171 Submitted, passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0046 TITLE: Unlimited polymorphic pointers in common blocks KEYWORDS: Unlimited polymorphic pointer, common block DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: PROGRAM foo COMMON /blk1/ x CLASS(*), POINTER :: x CALL sub END PROGRAM SUBROUTINE sub COMMON /blk1/ x CLASS(*), POINTER :: x END SUBROUTINE There appears to be nothing prohibiting an unlimited polymorphic pointer from appearing in a common block, but the following appears in Fortran 2003 at [100:10]: A data pointer shall be storage associated only with data pointers of the same type and rank. And at [75:23-25]: An object declared with the CLASS(*) specifier is an unlimited polymorphic object. An unlimited polymorphic entity is not declared to have a type. It is not considered to have the same declared type as any other entity, including another unlimited polymorphic entity. It appears that it is not standard conforming to have an unlimited polymorphic pointer that is storage associated with anything else, including another unlimited polymorphic pointer. So, while it is apparently standard-conforming to have an unlimited polymorphic pointer in a common block, a common block with the same name cannot be accessed in any other scoping unit. This interpretation also seems to be supported by parts of section 16 of the standard. At [416:7-24]: In a storage association context ... (8) A pointer occupies a single unspecified storage unit that is different from that of any nonpointer object and is different for each combination of type, type parameters, and rank. At [417:12-13]: All scoping units that access named common blocks with the same name shall specify an identical sequence of storage units. And at [417:14-17]: For any two blank common blocks, the initial sequence of storage units of the longer blank common block shall be identical to the sequence of storage units of the shorter common block. If two blank common blocks are the same length, they shall have the same sequence of storage units. Was it intended that an unlimited polymorphic pointer should be allowed in a common block? If yes, then was it intended that such a common block should be accessible in more than one scoping unit? ANSWER: No. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [98:20] Before "an allocatable variable", insert "a polymorphic pointer,". SUBMITTED BY: Rob James HISTORY: 05-137 m171 Submitted, passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0047 TITLE: Polymorphic arguments to intrinsic procedures KEYWORDS: polymorphism, intrinsic procedures DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The descriptions of the intrinsic procedures often use the term "type" without qualification. It is unclear whether they mean "declared type" or "dynamic type". If they mean "dynamic type", then this would appear to allow unlimited polymorphic arguments to intrinsic procedures like ABS and SIN. Resolution of generic intrinsic procedures in this case would create an undue (and likely unintended) burden on the processor, and the declared type of the result of such a function call would be unclear as well. Question 1: Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic? Question 2: (a) Is the ARRAY argument of the intrinsic function CSHIFT permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 3: (a) Are the ARRAY and BOUNDARY arguments of the intrinsic function EOSHIFT permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, then must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 4: (a) Are the A and MOLD arguments of the intrinsic function EXTENDS_TYPE_OF permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 5: (a) Are the TSOURCE and FSOURCE arguments of the intrinsic function MERGE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 6: Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC permitted to be polymorphic? Question 7: (a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 8: (a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 9: (a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 10: (a) Is the SOURCE argument of the intrinsic function SPREAD permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 11: (a) Is the SOURCE argument of the intrinsic function TRANSFER permitted to be polymorphic? (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? If the answer to (b) is yes: (c) If the MOLD argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 12: (a) Is the MATRIX argument of the intrinsic function TRANSPOSE permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 13: (a) Are the VECTOR and FIELD arguments of the intrinsic function UNPACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 14: Are any of the other arguments of any intrinsic procedure permitted to be polymorphic? ANSWER: Answer 1: Yes. Answer 2: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 3: (a) Yes. (b) Yes. (c) The requirements apply to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 4: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. Answer 5: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 6: Yes. Answer 7: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 8: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 9: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. Answer 10: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 11: (a) Yes. (b) No. (c) N/A. Answer 12: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 13: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 14: No. EDITS: [292:18+] Insert a new subclause 13.2 and re-number subsequent subclauses: 13.2 Polymorphic intrinsic function arguments and results Table 13.1 specifies the intrinsic functions that are allowed to have polymorphic arguments, and the arguments that are allowed to be polymorphic. Table 13.1: Polymorphic intrinsic function arguments --------------------------------------------------------------- | Function name | Arguments permitted to be polymorphic | =============================================================== | ALLOCATED | ARRAY, SCALAR | | ASSOCIATED | POINTER, TARGET | | CSHIFT | ARRAY | | EOSHIFT | ARRAY, BOUNDARY | | EXTENDS_TYPE_OF | A, MOLD | | LBOUND | ARRAY | | MERGE | TSOURCE, FSOURCE | | MOVE_ALLOC | FROM, TO | | PACK | ARRAY, VECTOR | | RESHAPE | SOURCE, PAD | | SAME_TYPE_AS | A, B | | SHAPE | SOURCE | | SIZE | ARRAY | | SPREAD | SOURCE | | TRANSFER | SOURCE | | TRANSPOSE | MATRIX | | UBOUND | ARRAY | | UNPACK | VECTOR, FIELD | =============================================================== The intrinsic functions shown in table 13.2 have a polymorphic result if and only if the specified argument is polymorphic. Where the result is specified to have the same type and type parameters as the argument specified in table 13.2, the result has the same dynamic type as the specified argument. If the specified argument is unlimited polymorphic the result is unlimited polymorphic; otherwise it has the same declared type as the specified argument. If another argument is required to have the same type as the specified argument, it shall be polymorphic if and only if the specified argument is polymorphic, and have the same dynamic type as the specified argument. If the specified argument is unlimited polymorphic, the other argument shall also be unlimited polymorphic; otherwise, it shall have the same declared type as the specified argument. Table 13.2: Polymorphic intrinsic function results ------------------------------------------------ | Function name | Argument that determines | | | result characteristics | ------------------------------------------------ | CSHIFT | ARRAY | | EOSHIFT | ARRAY | | MERGE | TSOURCE | | PACK | ARRAY | | RESHAPE | SOURCE | | SPREAD | SOURCE | | TRANSPOSE | MATRIX | | UNPACK | VECTOR | ================================================ SUBMITTED BY: Rob James HISTORY: 05-138 m171 Submitted - contained the questions/answers 05-138r1 m171 Contained the edits, passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i = 0 CONTAINS PROCEDURE, PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE CONTAINS RECURSIVE SUBROUTINE pwf(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, '(i1, /)') dtv%i WRITE(unit, '(t1, a2)') 'AB' END SUBROUTINE pwf END MODULE PROGRAM foo USE m IMPLICIT NONE TYPE(t) :: a a%i = 3 PRINT *, 'xyz', a end program 9.5.3.7.2 states: A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. The term "record position" is used, but it doesn't appear to be defined anywhere. Depending on the interpretation, the above program might be standard-conforming, or it might not be. If "record position" is taken to mean "the position within the current record", regardless of which record is the current record, then the record position at the beginning of the UDDTIO procedure is before the fourth character of the record. The first child data transfer statement begins a new record, and the second child data transfer statement writes to the first character of the new record. This would be before the "record position" at the time the UDDTIO procedure was invoked, and the program would not be standard-conforming. If "record position" is taken to mean a combination of the record and the position within that record (essentially making it mean the same thing as "file position"), then the above program is standard- conforming, since the control edit descriptor doesn't cause the file to be positioned before the record position when the UDDTIO procedure was invoked. What is the meaning of "record position", and is the above program standard-conforming? ANSWER: The term "record position" means the same as the term "file position". The program is standard-conforming. The PRINT statement prints xyz.3 AB where the first record starts with a space and the "." represents 0 or more spaces. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-139 m171 Submitted 05-139r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE m TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, *) dtv%i, 'a' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', & DELIM='NONE') WRITE(10, *), 'xyz', t1, 'zyx' END PROGRAM 10.9.2 of Fortran 2003 states that character sequences produced for list-directed output are not separated from each other by value separators when the delimiter mode is NONE. The implication of this is obvious when the adjacent effective output list items are both of character type. But when user-defined derived-type input/output is involved, it is much less clear whether a separator should be included in the output. In the example given, it is unclear whether the output should be: xyz 5 azyx or: xyz 5 a zyx 1. Should a separator be inserted between two non-delimited character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where both statements are list-directed? 2. Should a separator be inserted between two non-delimited character sequences when the character sequences are written by two different child data transfer statements, where both statements are list-directed? 3. Should a separator be inserted between two character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where one of the statements is list-directed and the other is format-directed? 4. Should a separator be inserted between two character sequences when the character sequences are written by two different child data transfer statements, where one of the statements is list-directed and the other is format-directed? ANSWER: 1) No. It is the intent of the standard that when both the parent and child data transfer statements are both list-directed output statements, or both are namelist output statements, the processor treats the first list item appearing in a child data transfer statement as if that list item had immediately followed the last list item processed by the parent data transfer statement, as long as no other data transfers to that unit occurred in between the processing of those two list items. Therefore, in this case, the two character sequences are considered adjacent. 2) No. It is the intent of the standard that when two different child data transfer statements are both list-directed output statements, or both namelist output statements, they write to the same unit, and no other data transfers to that unit occur in between the two child data transfer statements, the processor treats the first list item appearing in the second child data transfer statement as if that list item had immediately followed the last list item processed by the first child data transfer statement. Therefore, in this case, the two character sequences are considered adjacent. 3) It is processor dependent whether or not a separator appears between two such character sequences. In section 10.9.2, the phrase "adjacent undelimited character sequences" refers to character sequences produced by list directed output. When one of the sequences is written by a child or parent output statement that is not list directed, the exception described in the first paragraph of 10.9.2 does not apply. The other rules for inserting optional blanks around values in list directed output allow the processor to insert optional leading and trailing blanks around a list item. The standard does not specify when optional blanks are written; therefore, when two adjacent list items (the values thereof) are written to an output record, and only one of them was written by list directed I/O, the standard does not specify whether or not any optional blanks appear between those values in the output record. 4) It is processor dependent whether or not a separator appears between two such character sequences. See answer 3. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-140 m171 Submitted 05-140r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0051 TITLE: Repeat specifiers and UDDTIO KEYWORDS: repeat specifier, POS=, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i INTEGER :: j END TYPE INTEGER :: ipos INTERFACE READ(FORMATTED) MODULE PROCEDURE formattedReadT END INTERFACE CONTAINS SUBROUTINE formattedReadT (dtv, unit, iotype, vlist, iostat, iomsg) CLASS(T), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ(unit, *) dtv%i INQUIRE(unit, POS=ipos) READ(unit, *) dtv%j END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: a OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted') WRITE(10, '(A)') '2*3 5' REWIND(10) READ(10, *) a PRINT *, a%i, a%j, ipos END PROGRAM 10.9 of Fortran 2003 states that the r*c form of list-directed input is equivalent to r occurrences of c. So, when the read is performed, it is as if the input record contains two occurrences of the number 3. The first child read statement reads the first 3, and does not advance the file position to the next record (because it is a child data transfer statement). It appears that the second read statement should read the second 3. But the file position between the child read statements is unclear. What does the above program print? ANSWER: The standard does not specify the behavior of a processor when a list directed input record contains a r*c constant, and that entire set of input values is not completely consumed by one list directed input statement. In particular, the file position for such an input file when the processor is in the middle of consuming an r*c value, and a child input statement is invoked, is not defined. This was an oversight. Edits are supplied to prohibit r*c constants is this case. EDITS: [239:18] insert this paragraph before the paragraph that starts on [239:18] (just after note 10.28) "When a list item in a list directed input statement consumes the first value of an constant, that input statement shall consume all values of that constant before causing any child input statement to be invoked and before terminating if a parent input statement is active." SUBMITTED BY: Rob James HISTORY: 05-142 m171 Submitted 05-142r2 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0052 TITLE: ADVANCE= specifier in child data transfer statements KEYWORDS: ADVANCE=, UDDTIO, data transfer DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: The appearance of the ADVANCE= specifier in a child data transfer statement is not prohibited, but such an appearance is meaningless. 9.5.3 of Fortran 2003 states that the file is positioned after data transfer only if the statement is not a child data transfer. The appearance of the ADVANCE= specifier in such a statement would seem to serve only to confuse people maintaining a program that contains it. Was it intended that the ADVANCE= specifier should be allowed to appear in a child data transfer statement? ANSWER: Yes, it was intended that the ADVANCE= specifier should be allowed to appear in a child data transfer statement. Such a specifier has no effect. Note that a user defined derived type I/O routine can be called explicitly by the user, and in that case, the I/O statements therein are not child data transfer statements. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-143 m171 Submitted 05-143r1 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C589, p. 98 states "If a common-block-object is of a derived type, it shall be a sequence type (4.5.1) or a type with the BIND attribute and it shall have no default initialization." It also affects whether the types are extensible. 4.5.6 states "A nonsequence derived type that does not have the BIND attribute is an extensible type." 2. 15.2.2 states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. Yes, it was intended that these types have the BIND attribute. An edit makes this clear. 2. A user-defined derived type with the BIND attribute is permitted to have private components. DISCUSSION: 1. It was intended that the behaviour of these types be similar to that of user-declared derived types in all respects except that they interoperate with C pointer types rather than C struct types. As well as the two cases cited in the question, there are special conditions in a pointer assignment statement (7.4.2) if either the pointer or the target has the BIND attribute. Also, there is a restriction on types with the BIND attribute in a SELECT TYPE statement (8.1.5). 2. The rules for the interoperability of a C struct type with a Fortran derived type are less restrictive than the rules in 4.5.1.3 that determine whether two separately declared Fortran types, both with the BIND attribute, are the same. For the types to be the same, the names of corresponding components must agree and all components must be public. It follows that two types may be different although they both interoperate with the same C struct type. EDITS: Page and line numbers refer to 04-007. [397:3] Subclause 15.2.2. At the end of the first paragraph add "Each has the BIND attribute but is not interoperable with any C struct type." SUBMITTED BY: John Reid HISTORY: 05-151 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0054 TITLE: Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT KEYWORDS: denormal, intrinsic, EXPONENT, FRACTION, SET_EXPONENT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: What results do EXPONENT, FRACTION, and SET_EXPONENT return if the value of X is denormal? If a denorm is loaded into the cpu in extended precision, it becomes a normal value with changed fractional and exponent parts. Which of these values should be taken? In the definition of EXPONENT, the words 'of the model representation for the value of X' appear; but in the definition of FRACTION and SET_EXPONENT, the words are 'for the model representation of X'. Was this difference intended? ANSWER: In all three cases, the intention was to treat the value as if it were held according to the model in 13.14 with the same radix b, but with an expanded exponent range. This is why the words 'for the value of X' were used in EXPONENT. It has to be this way for a denormal value since otherwise it does not lie within the model. Edits are provided to make the intention clear. DISCUSSION: This interpretation is satisfactory from a mathematical point of view since the values of EXPONENT(X) and EXPONENT(DBLE(X)) will be the same when X is of type default real and has a denormal value. Similar properties holds for the other two functions. EDITS: Page and line numbers refer to J3/04-007. [316:5-6] Subclause 13.7.37, Result Value, lines 1-2. Replace "model ... X" by "representation for the value of X in the model (13.4) that has the radix of X but no limits on exponent values". [317:8] Subclause 13.7.40, Result Value, line 2. Replace "model ... X" by "representation for the value of X in the model that has the radix of X but no limits on exponent values". [351:5] Subclause 13.7.107, Result Value, line 2. Replace "model ... X" by "representation for the value of X in the model that has the radix of X but no limits on exponent values". SUBMITTED BY: John Reid HISTORY: 05-152 m171 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0055 TITLE: Denormal inputs to SPACING and RRSPACING KEYWORDS: denormal, intrinsic, SPACING, RRSPACING DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: What results do SPACING and RRSPACING return if the value of X lies outside the model of 13.4, in particular if it is denormal? In the definition of EXPONENT, the words 'of the model representation for the value of X' appear; but in the definition of SPACING and RRSPACING, the words are 'for the model representation of X'. Was this difference intended? Is the intention to indicate that for SPACING and RRSPACING, the model is that of all reals with the same kind type parameter value as X? In the IEEE model, the spacing between any two adjacent denorms is equal to the smallest denorm. Is it intended that this value be returned by SPACING? ANSWER: The informal description refers to 'model numbers near the argument value', but the text does not reflect this. Edits are provided to correct this. Yes, the difference was intended. In both models, the lower bound on the exponent has a profound effect on the spacing of tiny values, so it is important that it be taken into account. It was intended to refer to the model for all the reals with the same kind type parameter value as X. Here is it the model of 13.4 that is involved, as the words in 13.4 make clear. If the argument value is a positive denorm, the model numbers near it are TINY(X) and 0. Their spacing is TINY(X). Edits are provided to make this intention clear. EDITS: Page and line numbers refer to J3/04-007. [347:22] Subclause 13.7.100, Result Value, line 2. Replace "the model representation of X." by "the value nearest to X in the model for real values whose kind type parameter is that of X; if there are two such values, the value of greater absolute value is taken." [353:9] Subclause 13.7.113, Result Value, line 2. Replace "the model representation of X." by "the value nearest to X in the model for real values whose kind type parameter is that of X; if there are two such values, the value of greater absolute value is taken." SUBMITTED BY: John Reid HISTORY: 05-153 m171 Passed by J3 meeting ----------------------------------------------------------------------