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!

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

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!

<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]

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/

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

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!

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!

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!