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"