www.digitalmars.com         C & C++   DMDScript  

D - [Why] Additions on Integers not commutative

reply Manfred Nowak <svv1999 hotmail.com> writes:
Why is it good, that `a + b + c != b + a + c' for some integer variables
a, b, and c and some compiler C?

So long!
Apr 13 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Manfred Nowak wrote:

 Why is it good, that `a + b + c != b + a + c' for some integer variables
 a, b, and c and some compiler C?
 
 So long!


Overflow and underflow usually are the reason a standard arithmetic
identity is broken. If the sums were computed as
  a + (b+c) != b + (a+c)
then for the right values of a,b,c the sums will differ. For example
if a,b,c are signed bytes then
  100 + (-100 + 100) != -100 + (100 + 100)

Are you sure you meant "good" - did you mean "true"?

-Ben
Apr 13 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote:


 Overflow and underflow usually are the reason a standard arithmetic
 identity is broken.


[example omitted]

I exactly mean this case, because i just stumbled into it.



 Are you sure you meant "good" - did you mean "true"?


I mean good.

There are cases where an over-/underflow is unavoidable. In this
cases the stated inequality is simply true for _every_ compiler.

But in that cases like your example, where there is a permutation of the
operands that avoids an over-/underflow, my question gains room: why is it
good to allow a compiler to choose the bad permutation?

Shouldn't D go the safe way and require the compiler to choose the good
permutation, if there is one, and enable the coder to prevent the
compiler from this behaviour by fully bracing the expression?

I understand, that this would require sorting of the operands at runtime
and thus makes the executing slower.

Then: what is better?
To be portable and slower or to be unportable and more quick?

Unportable and more quick may retain to be the default, if there is a
possibility to code the choosing of the good permutation ... and vice
versa.

In the first case D is in the need to have an additional operator or
variadic functions. In the latter case I see no other chance as to have
an additional operator.

The case I stumbled into was even simpler:

long a= -100;
byte b= 100;
byte c= 100;

It follows, that a + ( b + c) != b + ( a + c).

But this defect is avoidable by simply choosing the long type as the type
every operand is implicitely converted to, before executing the operation.

This can be done at compile time, without the need of ordering at run time.

Would that be good to implement?

So long!
Apr 14 2004
next sibling parent reply John Q. Curmudgeon <John_member pathlink.com> writes:
<snip>

 Overflow and underflow usually are the reason a standard arithmetic
 identity is broken.


[example omitted]

There are cases where an over-/underflow is unavoidable. In this
cases the stated inequality is simply true for _every_ compiler.

But in that cases like your example, where there is a permutation of the
operands that avoids an over-/underflow, my question gains room: why is it
good to allow a compiler to choose the bad permutation?


</snip>

This is the first time I've heard of this. And I don't like it. If I say A+B+C I
_mean_ A+B+C, not A+(B+C) ! If it causes an exception, I wanna know! If I want I
can have a catch block that will use A+(B+C) if *I* choose !

Dagnabit!

[Sorry, he got away from us. -- JQC's therapist]
Apr 14 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
John Q. Curmudgeon wrote:

[...]

 If I say A+B+C I _mean_ A+B+C, not A+(B+C) !


[...]

Look at the specs!

So long!
Apr 18 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Manfred Nowak wrote:


Shouldn't D go the safe way and require the compiler to choose the good
permutation, if there is one, and enable the coder to prevent the
compiler from this behaviour by fully bracing the expression?
  


Parhaps for privative types but definitely not for objects (with 
operator overloads).  The programmer expects these to be called in a 
specific order.

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 15 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
J Anderson wrote:


 Parhaps for privative types but definitely not for objects (with 
 operator overloads).  The programmer expects these to be called in a 
 specific order.


This expectation is wrong according to the specs. If there is no bracing
the compiler is free to choose the sequence of evaluation.

So long!
Apr 18 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Manfred Nowak schrieb:


 Why is it good, that `a + b + c != b + a + c' for some integer variables
 a, b, and c and some compiler C?
 
 So long!


Can you give an example where this holds true? Integer additions and 
substractions always wrap over, so it doesn't matter in what order you 
add the 3 integers, it gives the same result. Due to ones-complement, 
there is no distinction between, say, an addition overflow and a 
substraction non-overflow either.

Problems may arise on machines which use other integer representation, 
but they have died out decades ago, and D was definately not made with 
them in mind. Since D already requieres a machine to have standard sizes 
and have either 32-bit or wider unified pointers, as well as IEEE 
floating point arithmetic, ones complement integer can be a requierement 
as well, its minor.

-eye
Apr 15 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Ilya Minkov wrote:


 Can you give an example where this holds true?


[...]

<code>
void main(){
  int a=int.max;
  long b= -int.max;
  int c=int.max;

  printf("%lld %lld\n", a + b + c, a + c + b);
}
</code>

output:
2147483647 -2147483649

So long!
Apr 18 2004