Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdchem!tps
From: tps@sdchem.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point
Message-ID: <659@sdchema.sdchem.UUCP>
Date: Mon, 6-Apr-87 22:38:11 EST
Article-I.D.: sdchema.659
Posted: Mon Apr  6 22:38:11 1987
Date-Received: Wed, 8-Apr-87 05:43:28 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM>
Sender: news@sdchem.UUCP
Reply-To: tps@sdchemf.UUCP (Tom Stockfisch)
Organization: UC San Diego
Lines: 79
Keywords: C Fortran Floating Point

In article <14680@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:

>In article <5716@brl-smoke.ARPA> gwyn@brl.arpa

>>C actually conforms more
>>closely to what a mathematician means by parentheses, which is to
>>group subexpressions in order to override default rules of operator
>>precedence....

>Doug, much as we all respect your knowledge of C and Unix, this
>just doesn't wash.  The essence of the problem is that floating point
>arithmetic is commutative but not associative.  From a mathematicians
>viewpoint 'x + y + z', where x, y, and z are floating point numbers
>and '+' is floating point addition, is not well defined.  I repeat,
>NOT WELL DEFINED.  The use of 'x op y op z' where 'op' is a two place
>operator is ambiguous:  it may either express
>
>	op(op(x,y),z) or op(x,op(y,z))

So what?  Even the operation 'x + y' is not well defined.  As everyone knows,
implementations have differing numbers of bits for mantissa and exponent,
different rounding schemes, and possibly different results if calculations
are done in registers.  Besides which, are you suggesting that when faced
with 'x + y + z' the compiler should warn that the expression is not
defined?  Or that this not even be allowed?

I think that the spirit of C is that the most common constructs tell the
compiler "Do the following in whatever way you want, hopefully the best
way for the machine you are on, given this particular broad outline.  If
I the details are important I'll have to specify that separately (and
perhaps more clumsily)."  For instance, "int i;" means 'i' is a word of the
handiest length for the machine.  If I need something that can hold the
difference between any two pointers, I have to say "long i;".

In this spirit, 'x + y' (if x and y are floating point) means "add x and y
together in the way customarily done on this machine".  '(x + y) + z' means
"add x, y and z in whatever way is best for this machine".  '+(x + y) + z'
means "add x and y first".

Whatever is finally decided for ANSI, I hope we do not lose the ability to
say to the compiler "do the following floating point calculation with only the
following broad outline".  Do numerical programmers really want most of their
operations done exactly in the order listed?  My experience has been that
most of the time, you don't.  It would be nice if there were a construct
which had a larger scope than does unary plus.  Some construct such as
	
	respect	expr;

where all the parentheses in "expr" are now "respected".  Or perhaps

	respect type f() { ... }

where parentheses are respected in the entire body of "f".

>If we are given an expression 'x op y op z' and 'op' is not associative
>then either we must use a predefined order of evaluation rule or the
>expression is not well defined.
>
>This is a question of mathematics, and is not, as you say, a question
>of Fortran versus C.  As it happens, the rules for evaluating expressions
>in Fortran are mathematically 'correct' in that they correctly model the
>mathematical properties of floating point numbers (in this instance),
>whereas those of C are not.

>....amount to asserting that for economic
>and historical reasons it is preferable to be living in a certain amount
>of mathematical 'sin' rather than to be mathematically 'pure' after the
>fact.  But please, do not misrepresent the mathematics of the situation.
>It is misleading to assert that the use of parantheses is simply a matter
>of grouping of common subexpressions.

I believe this is bogus because even implementations of Fortran are not
mathematically equivalent.  The question is, how much implementation-detail
do we want to force in the definition of '(x op y) op z'?  No matter how
this is chosen, numerical programs written on different machines can
produce different results.  This is not a question of mathematical sin.

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