From jkr@jkr.cc.rl.ac.uk Fri Mar 31 17:04:52 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 RAA30684 for ; Fri, 31 Mar 2000 17:04:50 +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 QAA11564 for ; Fri, 31 Mar 2000 16:04:49 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id QAA15154 for SC22WG5@dkuug.dk; Fri, 31 Mar 2000 16:05:55 +0100 (BST) Date: Fri, 31 Mar 2000 16:05:55 +0100 (BST) From: John Reid Message-Id: <200003311505.QAA15154@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1754) Interpretation 004 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > > Henry Zongaro wrote: > > 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. > > They certainly would be rather poor approximations, since the mathematical > real numbers have no infinities. > > They do not even have the semantics of being of larger magnitude than the > largest (finite) floating-point number - they just mean that they are the > result of an overflow at some point. E.g. > X = AINT(X*100)/100 ! Round X to 2 decimal places > will be "Infinity" for ABS(X)>HUGE(X)/100 on IEEE machines. Let me quote from section 6.1 of the IEEE standard: Infinity arithmetic shall be construed as the limiting case of real arithmetic with operands of arbitrarily large magnitude, when such a limit exists. Infinities shall be interpreted in the affine sense, that is, -inf < (every finite number) < +infinity. > These infinities really are "exceptional" values - which mean something like > "I don't know what the answer is, but it used to be big in the past...". No - you have not entered the spirit of the IEEE standard. The infinities are the best approximations available for numbers of very large magnitude. > I realise that since all floating-point values are approximations, the weird > properties of the infinities can be weaselled out of; I just consider that an > approximation in which not just all the mantissa is wrong but all the exponent > is wrong (and even the sign is likely to be wrong) Not if the code is written carefully. This is why Kahan needed zero to be signed, too. > is not a good enough > approximation. Others mileages doubtlessly vary. > > John Reid on 03/28/2000 05:34:06 AM wrote: > >>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 > > I disagree with the "should be". I would not object to "may be" > (though I still think it is the wrong thing to do). I maintain that only "should be" maintains the spirit of the IEEE standard. > >>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 > > ref the IEEE modules; by turning on overflow trapping (IEEE_SET_HALTING_MODE) > - which is the default on some systems - the production of infinities other > than by the artificial IEEE_VALUE method causes program termination. This > reinforces my viewpoint that these are more like exception values than like > approximations. Well, trying to evaluate the largest entry of any array of size zero is a bit like dividing by zero. I don't see that this behaviour as wrong. Cheers, John Reid.