From owner-freebsd-hackers Thu Apr 27 0:13:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 0617837B933 for ; Thu, 27 Apr 2000 00:13:15 -0700 (PDT) (envelope-from areilly@nsw.bigpond.net.au) Received: from areilly.bpc-users.org (CPE-144-132-171-71.nsw.bigpond.net.au [144.132.171.71]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id JAA04951 for ; Thu, 27 Apr 2000 09:34:35 +1000 (EST) Received: (qmail 82165 invoked by uid 1000); 26 Apr 2000 23:34:34 -0000 From: "Andrew Reilly" Date: Thu, 27 Apr 2000 09:34:34 +1000 To: Dan Nelson Cc: Sheldon Hearn , Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000427093434.A81401@gurney.reilly.home> References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> <20000426110345.A13173@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000426110345.A13173@dan.emsphone.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > In the last episode (Apr 26), Sheldon Hearn said: > > On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: > > > > Is FreeBSD's behavior correct? Why or why not? You can use the > > > > included code snippet to verify that this occurs. > > > > > > FreeBSD has traditionaly violated the IEEE FP standard in this > > > regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I > > > can't remember what file this is in so I can't check.) > > > > Huh? I'm pretty sure you've got this backwards. FreeBSD has > > traditionally upheld the standard and we only recently decided to go > > with the flow in 5.0. > > No; we held our moral ground against IEEE, until 5.0 when we gave in. > The IEEE standard says "trap nothing". For most programs, this is the > wrong thing to do, since they are not signal-processing apps or > numerical analysis programs and a divide by zero is a coding error. > I'd rather have my program die on an unexpected divide by zero than > continue with invalid data. > > Why should we treat (1.0/0.0) any differently from (1/0)? Because 0.0 might be the closest approximation to whatever number you were really trying to divide by that the hardware can manage. 0 is never an approximation to 1 or -1. Dividing is for wimps, anyway. :-) -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message