Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!purdue!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.misc
Subject: Re: IEEE floating point format
Message-ID: <3782@buengc.BU.EDU>
Date: 15 Aug 89 20:54:20 GMT
References: <2170002@hpldsla.HP.COM> <9697@alice.UUCP> <3554@buengc.BU.EDU> <9725@alice.UUCP> <3591@buengc.BU.EDU> <152@servio.UUCP> <3707@buengc.BU.EDU> <26756@amdcad.AMD.COM>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.misc
Organization: Boston Univ. Col. of Eng.
Lines: 26

In article <26756@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
>In article <3707@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>| 
>| Ulp!  You mean it does it absolutely silently now?  No provision at all
>| for a hardware (or software) portabl-ized belief that an implementation
>| will always perk up when the bits start to disappear??  I'm less impressed.
>
>No, there are two exceptions that can be signalled: underflow and
>inexact.  Underflow occurs when "tininess" is detected (or both tininess
>and loss of accuracy, if traps are disabled).

Is that underflow defined as when a number enters the subnormal
region, or when it is so small that even subnormal representation
isn't possible.

>Inexact occurs whenever
>the rounded result of an operation cannot be represented exactly.

You mean whenever the rounded result is not equal to the true result,
as a result of the decrease in digits that defines the rounding
operation.  I.e., whenever rounding actually does its job.

				--Blair
				  "Just want to disambiguate any
				   discrepancies in our disparate
				   discourse..."