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