Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!orchid!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdchem!tps
From: tps@sdchem.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point
Message-ID: <670@sdchema.sdchem.UUCP>
Date: Tue, 14-Apr-87 22:49:55 EST
Article-I.D.: sdchema.670
Posted: Tue Apr 14 22:49:55 1987
Date-Received: Fri, 17-Apr-87 05:08:27 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA>
Sender: news@sdchem.UUCP
Reply-To: tps@sdchemf.UUCP (Tom Stockfisch)
Organization: UC San Diego
Lines: 32
Keywords: C Fortran Floating Point Parenthases

In article <26916@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes:
>>Seriously, I cannot think of a SINGLE case in all my life when I suffered
>>from expression rearrangement...
>>--(Mike McNally (Man Insane))

>The physical constant h_bar is very
>close to zero and a number of physical equations involve h_bar squared.  This
>value was not representable in VAX floating point at the time.  I had to
>carefully arrange my expressions so that all intermediate values were in
>range.  For example, (foo / h_bar) / h_bar works, but the faster and
>mathematically equivalent expression foo / (h_bar * h_bar) does not work.
>  Lawrence Crowl		716-275-5766	University of Rochester

So you should have measured "foo" in units of
h_bar, (or h_bar squared?) then you
don't even need the division.  I
would find keeping track of what might overflow in
such a situation a horrible headache.
	
	(foo / h_bar) / h_bar
	
might just work, but then something
else a couple of expressions later might bomb out.
Also, you need comments all along the way to
explain your non-mathematically (as opposed to
numerically) arranged expression.




|| Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.ucsd.edu
					or  sdcsvax!sdchem!tps