Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!accelerator.eng.ohio-state.edu!kaa.eng.ohio-state.edu!rob From: rob@kaa.eng.ohio-state.edu (Rob Carriere) Newsgroups: comp.lang.c Subject: Re: How not to write a loop, revisited Message-ID: <329@accelerator.eng.ohio-state.edu> Date: 23 Jun 88 19:03:51 GMT References: <16276@brl-adm.ARPA> Sender: news@accelerator.eng.ohio-state.edu Reply-To: rob@kaa.eng.ohio-state.edu (Rob Carriere) Organization: Ohio State Univ, College of Engineering Lines: 29 In article <16276@brl-adm.ARPA> jrv%sdimax2@mitre-bedford.arpa writes: > [...] >I believe that floating point arithmetic is exact as long as all the values >are integers with not too many bits - and they typically allow more bits than >a long would. If there are exceptions to this, I'd like to hear about them. Ahem, I hope you are using tests on the loop that do not depend on exactness. If not, two things can go wrong: 1) somewhere in your computation, a roundoff error creeps in, and your results are no longer exact (example: raise a to the power b: for int's this is typically done by multiplication (exact), for floats by logarithms or similar (not exact, even if both a and b have integer values)). 2) you port to a machine with a slightly different floating point representation, and what used to be exact is no longer. In fact, now that I start thinking about it, some languages don't even guarantee that (representable number)*(representable number)=(1 of {representable number, overflow, underflow}). In the same vein, nobody I know *guarantees* that integers are representable (i.e. the closest approximation to 2 might be 1.999999) > > - Jim Van Zandt Rob Carriere "It's a poor computer that can think of only one way to confuse the issue"