Sat, 27 Oct 90 00:54:50 -0400

Related articles |
---|

[4 earlier articles] |

Re: IEEE 754 vs Fortran arithmetic dik@cwi.nl (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic wsb@eng.Sun.COM (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic eggert@twinsun.com (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic wsb@eng.Sun.COM (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic sjc@key.COM (1990-10-26) |

Re: IEEE 754 vs Fortran arithmetic diamond@tkov50.enet.dec.com (1990-10-15) |

Re: IEEE 754 vs Fortran arithmetic tim@ksr.com (Tim Peters) (1990-10-27) |

Re: IEEE 754 vs Fortran arithmetic bsy+@CS.CMU.EDU (Bennet Yee) (1990-10-28) |

Re: IEEE 754 vs Fortran arithmetic mcohen@amsaa-seer.brl.mil (Marty Cohen) (1990-10-30) |

Newsgroups: | comp.compilers |

From: | Tim Peters <tim@ksr.com> |

Keywords: | Fortran, arithmetic |

Organization: | Compilers Central |

Date: | Sat, 27 Oct 90 00:54:50 -0400 |

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 <grin>). I don't feel it's

*reasonable* to take an interpretation that reduces parts of the std to

meaninglessness.

*> [walt patiently <grin> 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

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.