From jkr@jkr.cc.rl.ac.uk Tue Jul 11 18:30:16 2000 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA52027 for ; Tue, 11 Jul 2000 18:30:16 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id RAA21600 for ; Tue, 11 Jul 2000 17:30:15 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id RAA11924 for SC22WG5@dkuug.dk; Tue, 11 Jul 2000 17:31:21 +0100 (BST) Date: Tue, 11 Jul 2000 17:31:21 +0100 (BST) From: John Reid Message-Id: <200007111631.RAA11924@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Interpretation 005 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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.' Here is the whole interpretation with this addition. Does anyone have any comments before I send this to J3? Best wishes, John. ---------------------------------------------------------------------- NUMBER: 000005 TITLE: Value returned by SELECTED_REAL_KIND KEYWORDS: SELECTED_REAL_KIND DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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. 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 ----------------------------------------------------------------------