Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!albanycs!crdgw1!sungod!davidsen
From: davidsen@sungod.crd.ge.com (ody)
Newsgroups: comp.lang.c
Subject: Re: Re^2: Turbo C 2.0 vs MSC 5.1
Message-ID: <1631@crdgw1.crd.ge.com>
Date: 11 Aug 89 14:33:41 GMT
References: <644@octopus.UUCP> <3607@cps3xx.UUCP> <7368@cg-atla.UUCP> <527@tigger.planet.bt.co.uk> <1989Aug9.094742.20000@gdt.bath.ac.uk>
Sender: news@crdgw1.crd.ge.com
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric Corp. R&D, Schenectady, NY
Lines: 23

In article <1989Aug9.094742.20000@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes:

| A bad move, I'd have said.  It is not difficult to think of cases where
| 'a/b/c/d/e' would give a sensible answer, while 'a/(b*c*d*e)' will
| overflow computing the denominator '(b*c*d*e)' and so give nonsense.

  Could you give us an example? Looking at the conditions it sure looks
as though even by avoiding the overflow you would be doing the
equivalent operations and would get an underflow on one of the divides.
I was also able to come up with values which give zero significant
digits without getting a trap.

  I can come up with a few cases where the order of operations was
important (ie big # times fraction times big # doesn't overflow, big #
time big # does, before the fraction). That's a diferent problem, since
order is needed for either multiplication or division.

  I assume that when you said "sensible answer" you meant "correct to
some useful number of digits" rathar than "avoids hardware errors."

	bill davidsen		(davidsen@crdos1.crd.GE.COM)
  {uunet | philabs}!crdgw1!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me