20 Jul 1998 17:00:17 -0400

Related articles |
---|

[8 earlier articles] |

Re: Is infinity equal to infinity? dwcantrell@aol.com (1998-07-13) |

Re: Is infinity equal to infinity? dwcantrell@aol.com (1998-07-13) |

Re: Is infinity equal to infinity? henry@spsystems.net (1998-07-13) |

Re: Is infinity equal to infinity? erikr@iar.se (Erik Runeson) (1998-07-20) |

Re: Is infinity equal to infinity? larry.jones@sdrc.com (Larry Jones) (1998-07-20) |

Re: Is infinity equal to infinity? darcy@usul.CS.Berkeley.EDU (1998-07-20) |

Re: Is infinity equal to infinity? darcy@usul.CS.Berkeley.EDU (1998-07-20) |

Re: Is infinity equal to infinity? darcy@usul.CS.Berkeley.EDU (1998-07-20) |

Re: Is infinity equal to infinity? joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-07-20) |

Re: Is infinity equal to infinity? miker3@ix.netcom.com (1998-07-21) |

Re: Is infinity equal to infinity? dwcantrell@aol.com (1998-07-24) |

From: | darcy@usul.CS.Berkeley.EDU (Joseph D. Darcy) |

Newsgroups: | comp.compilers |

Date: | 20 Jul 1998 17:00:17 -0400 |

Organization: | University of California, Berkeley |

References: | 98-07-058 98-07-108 |

Keywords: | arithmetic |

dwcantrell@aol.com (DWCantrell) writes:

[discussion of infinity == infinity]

*>But +oo is *also* used to represent overflow quite often! Then it does not*

*>represent the +infinity of the extended reals, but rather *any finite* number*

*>which exceeds the format's largest finite number. In this case, surely +oo*

*>should be treated as if it were NaN.*

[A suggestion from Knuth to basically treat overflow as NaN]

*>Let us now distinguish here between overflows, calling them +OF and -OF,*

*>and the infinities of the extended reals, calling them +oo and -oo. Then I*

*>think that ideally we should have -oo < -OF < x < +OF < +oo for all finite*

*>numbers x representable in the format, +oo = +oo, etc. But +OFs should*

*>be unordered with respect to each other, etc. (In fact, *ideally* I*

*>think that +OF = +OF should be considered as neither TRUE nor FALSE,*

*>but rather as INDETERMINATE.)*

One problem with introducing additional values like OF is that they in

turn must be able to participate in all floating point operations.

For example, 1/OF should generate a UF, an underflowed non-zero number

smaller than the smallest subnormal. Consistent rules for combining

OF and UF with everything else would have to be devised. Things like

OF may just slightly postpone the generation of a NaN. For example,

OF * UF should be a NaN. If an OF is generated from finite operands,

(exact value of the overflowing operation) * min_subnormal is a

representable number. However, the above scheme could not capture

that information without introducing still more kinds of numbers.

(Some of this sort of range information could be captured using a

suitable interval arithmetic).

Representing overflow with infinity loses information, but floating

point computation intrinsically loses information since a fixed

precision is used. For example, there are numbers so small that (1.0

+ num) == 1.0. The IEEE exceptional handling features (traps and

flags) can be used to implement floating point systems other than the

IEEE default completion having infinity and NaN. For example, the

sticky flags can be used to distinguish overflow from divide by zero

and enabling trapping on overflow stops the computation when any

non-exact infinity is generated.

Any one policy for handling overflow can be problematic. IEEE 754 has

the features to implement other policies (but these IEEE capabilities

aren't readily accessible in current popular programming languages).

-Joe Darcy

darcy@cs.berkeley.edu

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.