Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!dayton!rosevax!rose3!starfire!merlyn
From: merlyn@starfire.UUCP (Brian Westley)
Newsgroups: comp.lang.c
Subject: Re: + != + (floating point)
Message-ID: <134@starfire.UUCP>
Date: Sun, 26-Apr-87 12:24:43 EDT
Article-I.D.: starfire.134
Posted: Sun Apr 26 12:24:43 1987
Date-Received: Sat, 2-May-87 06:47:15 EDT
References: <133@starfire.UUCP> <1285@ubc-cs.UUCP>
Organization: Starfire Consultings Services, Mpls., MN
Lines: 36

Vincent Manis writes:
> I write:
> >Integer addition is communative [sic] & associative.  Floating addition is
> >communative, but NOT associative.
[oops, s/communative/commutative/g - Ed]
> 
> This statement is flat-out wrong. On a machine with 16-bit ints 
> 
>    32767 + (-2) + 1
> 
> and 
> 
>    32767 + 1 + (-2)
> 
> may lead to different results....[etc]

  Yes, but I wasn't talking about expressions that lead to overflow (which is
another kettle of fish, since your version of C may or may not rearrange
integer expressions, which may or may not produce an integer overflow, which
may or may not be trapped as an error, which may or may not produce the correct
answer ANYWAY, depending on your machine & compiler).

  I was talking of the general case of:
	(1 + 9999) + (-9999)		(same no matter how you slice it)  vs.
	(1 + 9E99) + (-9E99)		(not the same)

I am also not against +(), as integer overflow is a case where order of
evaluation is important (but I like the suggested [] notation better).
I was just against compilers performing associative transformations on
operators that aren't associative, PERIOD.  As other people have pointed
out, a compiler isn't REQUIRED to rearrange floating-point expressions
associatively, and if there is enough demand for such behavior, maybe it
will become a de facto "standard".

Merlyn Leroy
...rutgers!dayton!rosevax!rose3!starfire!merlyn