Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!olivea!mintaka!spdcc!esegue!compilers-sender From: tim@ksr.com (Tim Peters) Newsgroups: comp.compilers Subject: Re: IEEE 754 vs Fortran arithmetic Keywords: Fortran, arithmetic Message-ID: <9010270454.AA03364@lunch.ksr.com> Date: 27 Oct 90 04:54:50 GMT Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: Tim Peters Organization: Compilers Central Lines: 105 Approved: compilers@esegue.segue.boston.ma.us In article <144188@sun.Eng.Sun.COM> wsb@eng.Sun.COM (Walt Brainerd) writes: >In article <9010242205.AA04208@lunch.ksr.com>, tim@ksr.com (Tim Peters) >writes: >> [X.EQ.Y means ((X)-(Y)).EQ.0 under F77 rules, and this creates >> problems under 754] > [walt explains that this clause applies only when X and Y are > different types] Yes, agreed -- thanks for clarifying. The example should have had, e.g., DOUBLE PRECISION X REAL Y The conclusions are unchanged. >This text is there to explain how to do type conversion when >X and Y are different types. I agree that was the intent. Unfortunately, that's not what the F77 text says. A possible correction: F90 may have fixed this problem after all. I noticed today in the S8.115 draft of F90 that the goofy phrasing of the F77 standard is gone, replaced by words that clearly get at the type conversion intent without F77's harmful overspecification. Hope the new text survives. >> [tim whining about various 754 vendors evaluating entire expressions >> in an extended precision before cutting back to "storage precision"] >Since there is nothing in the F77 standard that indicates how much >precision should be used for anything, such an evaluation cannot >violate F77. (IMHO) ... We disagree, but launching into an argument about what F77 does & doesn't say would take us out of the "754 vs Fortran" topic, so I'll just sketch the opposing view below. More important to the topic at hand is that the extended precision gimmicks are clearly against both the letter and the spirit of the 754/854 stds, under any implementation that's claiming to map Fortran's "+" "-" "*" "/" REAL and DOUBLE operator symbols into the addition (etc) operations defined by 754/854. The results of the 754 operations are defined down to the last bit, and any implementation doing the extended-precision stuff cannot meet those definitions (e.g., because of double rounding errors). conforming processor from, e.g., evaluating "X+Y" in REAL X, Y, Z Z = X+Y in an extended precision (or, for that matter, in a reduced precision, or even unconditionally evaluate all sums to -6.5!), I do not agree that the std allows that freedom across the entire RHS in Z = X + (Y + Z) or even in Z = X + Y + Z Section 6.1.4 clearly defines the type of all *sub*expressions in the above to be REAL, and to say that the "mathematically equivalent" freedoms allow one to carry *more* than REAL precision out of the REAL subexpressions into their contexts is to squeeze all meaning out of "mathematically equivalent", Fortran's notion of type, or both. Since F77 is not in any sense a formal or rigorous std, this is a matter of interpretation (but so is everything else ). I don't feel it's *reasonable* to take an interpretation that reduces parts of the std to meaninglessness. > [walt patiently explaining that Fortran cannot guarantee > results consistent with what 754 requires] Yes, of course. But Fortran can & should change to allow 754 vendors to meet both stds simultaneously without logic-chopping and brutal contortions. The change in S8.115 to the definition of relationals is a good example of what can be done to further this end. It is unfortunate that F90 didn't consciously address 754/854 issues. It is also unfortunate-- & more so! --that 754/854 did not consciously address language binding issues from the start. As other people here are pointing out already, the *real* pain isn't the (very) few areas in which 754 and Fortran flat-out contradict each other, it's the many areas in which the 754 features are a poor fit with Fortran (and C ...). What to do with a NaN in an arithmetic IF is a darned good question. Optimize IF (X.NE.X) PRINT *, 'Found a NaN!' out of existence because X.NE.X is relationally equivalent to .FALSE. and the 754 user is in for more exceedingly nasty surprises. Have some vendors using their extended-precision gimmicks and others not and the fact that 754 defines a "portable" arithmetic is reduced to an academic footnote. Etc. Etc. some-de-facto-std-will-eventually-arise-out-of-this-mess-but-for-now- it-is-indeed-a-mess-ly y'rs - tim Tim Peters Kendall Square Research Corp tim@ksr.com, ksr!tim@harvard.harvard.edu -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.