Path: utzoo!attcan!uunet!sdrc!scjones From: scjones@sdrc.UUCP (Larry Jones) Newsgroups: comp.lang.c Subject: Re: Re^2: Turbo C 2.0 vs MSC 5.1 Message-ID: <778@sdrc.UUCP> Date: 12 Aug 89 17:31:35 GMT References: <644@octopus.UUCP> <3607@cps3xx.UUCP> <7368@cg-atla.UUCP> <1631@crdgw1.crd.ge.com> Organization: Structural Dynamics Research Corp., Cincinnati Lines: 23 In article <1631@crdgw1.crd.ge.com>, davidsen@sungod.crd.ge.com (ody) writes: > 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. For simplicity, lets consider just a/b/c vs. a/(b*c). If a and b are equal and very large (like DBL_MAX, for example) and c is some small integral value (like 2.0), then a/b/c is a quite reasonable, representable value (0.5), but a/(b*c) causes an overflow (since 2.0 * DBL_MAX is not representable). ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "I have plenty of good sense. I just choose to ignore it." -Calvin