Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!think.com!compass!worley
From: worley@compass.com (Dale Worley)
Newsgroups: comp.lang.c
Subject: Re: Short circuit evaluation/expression rearrangement (2nd summary)
Message-ID: <WORLEY.91May31101732@sn1987a.compass.com>
Date: 31 May 91 14:17:32 GMT
References: <1991May27.113628.26880@ucthpx.uct.ac.za> <16283@smoke.brl.mil>
	<1991May30.151211.16891@Daisy.EE.UND.AC.ZA>
Sender: root@compass.com
Organization: Compass, Inc., Wakefield, MA, U.S.A.
Lines: 27
In-reply-to: barrett@Daisy.EE.UND.AC.ZA's message of 30 May 91 15:12:11 GMT


   In article <16283@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
   > >... in "a + b + c",
   > >the first addition must be performed before the second, because it
   > >associates as "(a + b) + c", showing that the second addition has as
   > >an argument the result of the first.
   > 
   > The above is incorrect.  A conforming implementation is obliged to
   > perform the operations so that it doesn't create an exception where
   > one would not have occurred in evaluating the expression strictly
   > according to the precedence implied by the grammar, but within
   > those constraints it may perform the additions in any order.  To
   > force an order of evaluation (in Standard C), you must use parentheses.

However, if the computation is floating-point, problems can arise
above and beyond exceptions.  The usual problem is loss of
significance.  See section 3.3 of the Rationale of the C standard for
an explanation, which makes it clear that (in Standard C) a + b + c
*must* be evaluated as (a + b) + c if a, b, and c are floating point.

(Also, beware that the Rationale claims that Fortran has the same
no-regrouping rule as the C standard.  That's not true.)

Dale Worley		Compass, Inc.			worley@compass.com
--
Dammit, we're all going to die, let's die doing something *useful*!
-- Hal Clement, on comments that space exploration is dangerous