Xref: utzoo comp.lang.c:6427 comp.lang.fortran:353
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!purdue!i.cc.purdue.edu!j.cc.purdue.edu!ags
From: ags@j.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: Strict parens not sufficient
Keywords: floating-point ANSI C numerical analysis
Message-ID: <6210@j.cc.purdue.edu>
Date: 20 Jan 88 17:14:05 GMT
References: <546@cresswell.quintus.UUCP>
Reply-To: ags@j.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 55

In article <546@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>Formerly, C treated parentheses according to mathematical practice:
>they had only a grouping effect, and whether (a+b)-c was reordered
>or not was up to the compiler.
>FORTRAN and some other languages give parentheses an operational
>effect as well.  That is, (a+b)-c and a+b-c are different expressions
>and the programmer is entitled to assume that the calculation is as
>written, not (a-c)+b or any other re-ordering.

>... The snag with the FORTRAN
>method is that you get strict ordering whether you want it or not.

It is not true that FORTRAN gives you strict ordering.  Taking your
example, if a FORTRAN programmer writes (a+b)-c, then he is entitled to
assume that it is interpreted as one of the following:

	(a+b)-c
	(b+a)-c
	-c+(a+b)
	-c+(b+a)

but not as:

	(a-c)+b		(b-c)+a
	(-c+a)+b	(-c+b)+a
	b+(a-c)		a+(b-c)
	b+(-c+a)	a+(-c+b)

The C programmer, on the other hand, cannot rule out any of the
interpretations in the second group.  The difference is crucial because
floating point arithmetic is commutative but not associative.  Therefore
the FORTRAN programmer knows that the value of the expression cannot be
changed by the compiler's evaluation order, while the C programmer has no
such assurance.

>It seems to me that FLOAT()/(float) and DBLE()/(double) should mean
>"convert the operand to exactly the precision that would be given
>to a REAL {DOUBLE PRECISION} variable in storage."
>Note that only converting an expression which already appears to
>have the desired type is changed, and then only if intermediate
>results are calculated in a higher precision.  Most programs should
>notice no change.
>
>Without this definition in the standard, you have to explicitly
>introduce temporary variables, ....

This seems to be a reasonable requirement, especially in view of the fact
that without it you have absolutely no guarantee, EVEN IF YOU INTRODUCE
TEMPORARY VARIABLES, that the result will be as it would be stored in
memory.  This is because an optimizing compiler is perfectly free to assign
your temporary variables to registers rather than to memory.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu