From zongaro@ca.ibm.com Wed Mar 29 20:38:26 2000 Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA22997 for ; Wed, 29 Mar 2000 20:38:24 +0200 (CEST) (envelope-from zongaro@ca.ibm.com) From: zongaro@ca.ibm.com Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA91086 for ; Wed, 29 Mar 2000 13:34:49 -0500 Received: from d53mta05h.boulder.ibm.com (d53mta05h.boulder.ibm.com [9.99.142.5]) by westrelay02.boulder.ibm.com (8.9.3m3/NCO v2.07) with SMTP id LAA34804 for ; Wed, 29 Mar 2000 11:38:22 -0700 Received: by d53mta05h.boulder.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 872568B1.00666299 ; Wed, 29 Mar 2000 11:38:19 -0700 X-Lotus-FromDomain: IBMCA@IBMUS To: SC22WG5@dkuug.dk Message-ID: <872568B1.00665FEC.00@d53mta05h.boulder.ibm.com> Date: Wed, 29 Mar 2000 13:42:09 -0500 Subject: Re: (SC22WG5.1733) Interpretation 004 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I think we need to be careful with this interpretation question. It's never been clear to me that IEEE infinity and negative infinity could be considered to be real values by a standard-conforming program. I believe it all depends on how a processor claims to provide support. For instance, 4.3.1.2 of the Fortran 95 standard states that "The real type has values that approximate the mathematical real numbers". IEEE infinity doesn't seem to fit that description. A more important problem lies with the I/O representation of infinity; processors typically will print an IEEE infinity as "Inf" or "infinity". Referring to 10.8.2, list directed output, we find the following description which requires a processor to use something that has the effect of F or E editing. Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, depending on the magnitude x of the value and a range 10**d1<=x<10**d2, where d1 and d2 are processor-dependent integers. If the magnitude x is within this range, the constant is produced using 0PFw.d; otherwise, 1PEw.dEe is used. The description of real and complex editing in 10.5.1.2 doesn't seem to allow for the string of letters "infinity" to be produced as the result of the following program. If a processor does, I don't think it can claim that IEEE infinity is a real value, and I think that a program that produced an IEEE infinity on such a processor couldn't be standard conforming. REAL :: R R = HUGE(1.0)**2 PRINT *, R END Now, if a processor considered IEEE infinity to be some *finite* value outside of the "usual" range for real values of that kind (such as 2*HUGE(1.0_realkind)), and represented the value accordingly in I/O, then I think that it would be OK for such a processor to use an IEEE infinity as the result of MINVAL with a zero-sized real array. I don't necessarily think that the response to this interpretation needs to be rewritten; I just want to make sure that implementors don't produce a result value for MAXVAL on a zero-sized array that would render a program like the following non-conforming on their processors. REAL :: R(0) PRINT *, MAXVAL(R) END Thanks, Henry ------------------------------------------------------------------------ Henry Zongaro IBM Distributed Debugger Development IBM SWS Toronto Lab Tie Line 778-6044 Phone (416) 448-6044 Internet id: zongaro@ca.ibm.com John Reid on 03/28/2000 05:34:06 AM Please respond to John Reid To: SC22WG5@dkuug.dk cc: Subject: (SC22WG5.1733) Interpretation 004 Date: 28th March 2000 To: J3 From: John Reid Subject: Interpretation 004 Here are drafts for the ANSWER and EDITS sections of 004. Also, I propose that the addendum be removed. For your convenience, the current 004 is attached. ANSWER: Processors may support values that are not present in the model of 13.7.1. IEEE -inf is an example of such a number and this should be returned on a machine that supports the IEEE standard. If the negative number of largest magnitude in the model had been intended, the model would have been mentioned as, for example, in the definition of HUGE (13.14.39). A simple example of its use is to test whether a set of numbers SET1 has a value greater than any value in the set SET2. Consider the expression MAXVAL(SET1)>MAXVAL(SET2). If SET1 is empty and SET2 is not, this value is (correctly) false even if all the values are outside the model with values less than -HUGE(SET1). It may be helpful to consider how MAXVAL might be coded for an array of rank one on an IEEE computer. The following code is suitable MAXVAL = IEEE_VALUE(1.0,IEEE_NEGATIVE_INF) DO I = 1, SIZE(ARRAY) MAXVAL = MAX(MAXVAL,ARRAY(I)) END DO EDITS: None. ------------------------------------------------------------------------------- NUMBER: 000004 TITLE: Value returned by MAXVAL/MINVAL KEYWORDS: MAXVAL, MINVAL DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: The Result Value section of the MAXVAL intrinsic function description uses the phrasing: or has the value of the negative number of the largest magnitude supported by the processor for numbers of the type and kind type parameter of ARRAY if ARRAY has size zero This phrasing has generated at least the two following views on the return value: * If the machine supports the IEEE standard then the implementation should return -inf. * For portability, the implementation should return -HUGE(ARRAY). These views lead to the following questions: 1. Is the intent of the standard to describe the result in terms of machine values rather than model values? 2. If the answer to 1 is "yes", how are programmers expected to use this intrinsic function portably? ANSWER: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-240 m143 submitted - - - - - - - Date: Thu, 18 Sep 1997 13:38:50 -0500 [ From a coworker here at SGI/CRI ] The first question boils down to: on an IEEE-like hardware platform which has a bit pattern for -infinity, does this qualify as "a value ... supported by the processor"? The result of MAXVAL must be of the same type and kind as the argument. Since -infinity would only be possible if the arguments were of type real, one would have to conclude that -infinity was a valid real value. If that is true, then there would be at least one argument for which some intrinsics (EXPONENT, FRACTION) would fail. Based on this I would argue that returning -infinity should be invalid. I also think it is unwise, based on the discussion below. I think that the real problem is that there is no clean way to return a "failed" status from MAXVAL. Both the -huge() and the -infinity methods are defective attempts at solving that problem. It is not clear that the choice of -infinity is in any way superior to -HUGE(). If a machine allows -infinity, and all the tested elements in the array were -infinity, then you would expect that -infinity would be returned. But then is it the "answer" or is it an "error"? There is no way to tell. Returning -HUGE() suffers from exactly the same defect. I believe that there are a couple of drawbacks to the use of -infinity. 1) You might like to write code of the following form: answer = maxval(array, mask=larray) if (answer == xxxxx) then ! code for the case that all the elements in larray are .false. else ! code the the cae that answer is a meaningful result end if What do you use for xxxxx? In the current model, -HUGE(array) should be a workable and portable form. If the alternate -infinity version were used, then there would have to be a way in Fortran to represent -infinity. It's not clear that is always possible, and most likely not in a portable fashion. 2) The MAXVAL function allows either real or integer arguments. On an IEEE machine (for example) -infinity only has meaning for reals; the concept of -infinity makes no sense for integer arguments. It seems an unnecessary complication to have one scheme for reals and a different one for integers. -------------------------------------------------------------------------------