From malcolm@brackley.nag.co.uk Fri Mar 31 18:52:37 2000 Received: from brackley.nag.co.uk ([62.232.54.10]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA31016 for ; Fri, 31 Mar 2000 18:52:32 +0200 (CEST) (envelope-from malcolm@brackley.nag.co.uk) Received: (from malcolm@localhost) by brackley.nag.co.uk (8.9.2/8.9.2) id RAA78312 for SC22WG5@dkuug.dk; Fri, 31 Mar 2000 17:51:40 +0100 (BST) (envelope-from malcolm) From: Malcolm Cohen Message-Id: <200003311651.RAA78312@brackley.nag.co.uk> Subject: Re: SC22WG5.1764) Interpretation 004 To: SC22WG5@dkuug.dk Date: Fri, 31 Mar 2000 17:51:40 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John Reid wrote: > 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. >> [I wrote] >> 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. Quote away - the mathematical REAL number line is not defined by the IEEE standard. Like presumably many others here I studied the axioms of the mathematical REALs at college well before the IEEE standard existed - "the mathematical real numbers have no infinities". [I'm using "REAL" in this message to mean the mathematical reals here, since this character set doesn't include the right sort of script capital R.] You will notice that the quoted text does not claim that the infinities are approximations to any REAL numbers. Indeed, with my pure maths hat on the quoted text claims that they are ***NOT*** an approximation to any REAL number - they are additional elements that are not in the set of REALs. (If they were in the set of REALs, they would not have needed to use the "limit" terminology; and using the "limit" terminology puts them outside). >> 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. The error between "infinity" and the correct answer is infinite, so in a sense these are the worst approximations! Zero is a better one! Anyway the point of my example was that IEEE postulation to the contrary, these things are not good approximations to REAL numbers of very large magnitude. (The overflow in my example being in the past, not in the true mathematical result). [And according to text you quoted, IEEE don't really postulate to the contrary anyway.] Emphasis on the "not good approximations" (I don't dispute that they are very poor ones!) - and my considered opinion that they are not "good enough" for the situation at hand. And Henry made the point that if they are some sort of approximation to a large number, that number should be printed on output not "INF". ["even the sign is likely to be wrong"] >Not if the code is written carefully. Well, so few people write the code that carefully (and so few optimisers respect the code that well) that to a first approximation we might as well say that no-one does. But in any case, the entire mantissa and exponent are known to be wrong. If you get lucky (or are one of the few careful people, or using one of the few careful person's codes) the sign will be right. >This is why Kahan needed zero to be signed, too. OTOH, the 2-point compactification of the REALs (viz REALs plus the 2 infinities, which is apparently what IEEE is trying to look like) doesn't have multiple zeroes... ... I think signed zeroes as much about interval arithmetic and branch cuts for complex functions than for infinity signedness (at least that's the impression I get from Kahan's paper on complex elementary functions). >I maintain that only "should be" maintains the spirit of the IEEE standard. I think the letter of the Fortran standard overrides the spirit of IEEE. Besides ... the IEEE standard is a "floating-point number" standard which includes things that are not "approximations to REAL numbers". It is not denigrating the IEEE standard to say that some of its constructs are not approximations to REALs - particularly since their infinities seem to be modelled on the 2-point compactification of the REALs and not on the REALs themselves (which have no infinities) or the 1-point compactification (which has only 1 infinity) etc. i.e. an IEEE "value" includes things that are not "Fortran-real" values. We already know this - the various NaNs are not approximations to REAL values (and in this case they aren't approximations to things in "REAL+2" either). I see no proposal to say that NaNs are "Fortran-real" values that implementors ought to return in any particular situation, but they are just as much a part of IEEE-754 as the infinities are. [Aside: If one thinks of these returns from MAXVAL/MINVAL as "error returns", and the infinities as "normal numbers" (which one of the writers did), then +/- QNaN is more appropriate to return! I don't think so though.] Still, you could add the edit [32:35] Before "the mathemathical real numbers" Insert "the 2-point compactification of". I wouldn't have a leg to stand on then! There is also the question (also raised in the interp) as to what FRACTION and EXPONENT are expected to do here. If we are going to claim that +INF and -INF are pukka Fortran-real values, it behooves us to explain what the poor user is going to get from doing the normal Fortran-ish things with them; i/o, FRACTION and EXPONENT are not obvious - perhaps SPACING and RRSPACING are more obvious. NEAREST(+Inf,+1.0) seems broken (there is no such value for it to return - the definition in 13.14.76 does not make sense for this case). If assuming +Inf is a pukka Fortran-real number causes a contradiction (elsewhere in the standard - which it does for NEAREST at the very least) then that assumption is wrong. (Proof by contradiction). That is why I object to recommending that +/-INF are valid Fortran-real numbers unless and until the rest of the standard accommodates such exceptional values. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)