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