25 Oct 90 17:03:07 GMT

Related articles |
---|

IEEE 754 vs Fortran arithmetic robertsj@admin.ogi.edu (John Roberts) (1990-10-22) |

Re: IEEE 754 vs Fortran arithmetic burley@world.std.com (1990-10-24) |

Re: IEEE 754 vs Fortran arithmetic henry@zoo.toronto.edu (1990-10-24) |

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

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,comp.lang.fortran |

From: | wsb@eng.Sun.COM (Walt Brainerd) |

Followup-To: | comp.lang.fortran |

Keywords: | Fortran |

Organization: | Compilers Central |

References: | <9010242205.AA04208@lunch.ksr.com> |

Date: | 25 Oct 90 17:03:07 GMT |

In article <9010242205.AA04208@lunch.ksr.com>, tim@ksr.com (Tim Peters) writes:

*> *

*> But there are other problems. E.g., the meaning of*

*> *

*> X.EQ.Y*

*> *

*> is *defined* by F77 to be the value of*

*> *

*> ((X-Y).EQ.0)*

*> *

*> (pg 6-10, lines 4-14), and Fortran's usual "must respect parens" rules*

*> prevent a conforming processor from transforming the subtraction into a*

*> "mathematically equivalent" comparison operation (although every vendor*

*> with a comparison instruction cheats here ...).*

The referenced lines begin:

"If the two arithmetic expressions are of different types, ..."

^^^^^^^^^^^^^^^

so this does not apply if X and Y both are real, for example.

This text is there to explain how to do type conversion when

X and Y are different types. Thus, I don't think compilers that

use a relational operator are "cheating".

*> Perhaps the most widespread "problem" is that 754 vendors tend to like*

*> to evaluate entire expressions in an extended precision and cut back the*

*> result to "storage precision" only at the end. This violates my reading*

*> of both the F77 and 754 stds.*

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)

Yes, there are some words that indicate when you should convert from one

precision to another, but there is nothing that says how much any particular

precision there should be for anything (there are requirements on how

equivalence must work between them, but this only affects how stored results

must align, not expression evaluation and not the values stored).

*> None of the Fortran problems will be repaired by F90.*

The real "problem" is: according the the F77 _standard_, there is no way to

be sure that real arithmetic is done by any particular scheme, so any program

that tries to depend on a specific result (i.e., comparing two reals for

equality) or expecting the result of any real operation to be precise within

certain limits, is nonportable. You certainly may have your own criteria

about how things should work and pick a vendor that does things that way, but

there is no help for you in the standard.

The only reasonable "repair" I can think of is to require all arithmetic to

be done as IEEE 754, or some such, a position that clearly is not acceptable

to all vendors this year.

The new KIND mechanism in Fortran 90 will at least allow the programmer to

indicate that a variable has a certain number of digits of precision; I think

this should help some.

--

Walt Brainerd Sun Microsystems, Inc.

wsb@eng.sun.com MS MTV 5-40

Mountain View, CA 94043

415/336-5991

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.