Mon, 16 Nov 1992 01:19:25 GMT

Related articles |
---|

IEEE arithmetic handling jim@meiko.co.uk (1992-11-11) |

Re: IEEE arithmetic handling tmb@arolla.idiap.ch (1992-11-16) |

Re: IEEE arithmetic handling eggert@twinsun.com (1992-11-16) |

Re: IEEE arithmetic handling bill@amber.csd.harris.com (1992-11-16) |

Re: IEEE arithmetic handling jlg@cochiti.lanl.gov (1992-11-17) |

Re: IEEE arithmetic handling eggert@twinsun.com (1992-11-17) |

Re: IEEE arithmetic handling tmb@arolla.idiap.ch (1992-11-18) |

Re: IEEE arithmetic handling bart@cs.uoregon.edu (1992-11-19) |

[4 later articles] |

Newsgroups: | comp.compilers |

From: | tmb@arolla.idiap.ch (Thomas M. Breuel) |

Organization: | IDIAP |

Date: | Mon, 16 Nov 1992 01:19:25 GMT |

References: | 92-11-041 |

Keywords: | arithmetic, design |

jim@meiko.co.uk (James Cownie) writes:

Another area where IEEE seems never to be implemented correctly by

compilers is in the handling of Not a Numbers (NaNs). [...]

(.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)

[...] Similarly (and I've never seen this handled right in an optimising

compilation),

IF (X .ne. X) THEN

print *,'X is a NaN'

ELSE

print *,'X is a number'

ENDIF

should generate code which has a run time test.

You are making the assumption that the usual language primitives for FP

("=", "<", ".ne.", etc.) should map directly on IEEE operations. That is

certainly not mandated by most current language standards, and I have

serious doubts that it should be mandated.

An alternative approach, and one which I prefer, is that it is an error to

use the usual language primitives for arithmetic with NaN's (as usual, if

you compile for safety, this error should be detected at runtime, if you

compile for speed, you simply get undefined results). You should have to

use special IEEE primitives ("is_nan(x)", "ieee_less(x,y)") to get at the

IEEE meanings when available.

Why do I prefer this? IEEE operations are implementation specific and

unportable, in the sense that not all implementations of a programming

language support them. When you rely on implementation specific and

unportable features, you should have to express that reliance explicitly

so that when I have to port your code, I can figure out what I have to

change.

Note that even if every computer in the universe supported IEEE floating

point, you would still want to make a clear distinction between the usual

numerical operations and IEEE-specific behavior. The reason is that you

might want to use your numerical code with software implementations of

other kinds of floating point numbers, implementations that may not be

able to support IEEE features.

Thomas.

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.