Integer overflow and underflow semantics?

[Don via Digitalmars-d]

On Tuesday, 22 July 2014 at 15:31:22 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 22 July 2014 at 11:40:08 UTC, Artur Skawina via 
> Digitalmars-d wrote:
>> obey the exact same rules as RT. Would you really like to use 
>> a language
>> in which 'enum x = (a+b)/2;' and 'immutable x = (a+b)/2;' 
>> results in
>> different values?...
>
> With the exception of hash-functions the result will be wrong 
> if you don't predict that the value is wrapping. If you do, I 
> think you should make the masking explicit e.g. specifying 
> '(a+b)&0xffffffff' or something similar, which the optimizer 
> can reduce to a single addition.
>
>> That's how it is in D - the arguments are only about the 
>> /default/, and in
>> this case about /using a different default at CT and RT/. 
>> Using a non-wrapping
>> default would be a bad idea (perf implications, both direct and
>
> Yes, but there is a difference between saying "it is ok that it 
> wraps on addition, but it shouldn't overflow before a store 
> takes place" and "it should be masked to N bits or fail on 
> overflow even though the end-result is known to be correct". A 
> system level language should encourage using the fastest 
> opcode, so you shouldn't enforce 32 bit masking when the 
> fastest register size is 64 bit etc. It should also encourage 
> reordering so you get to use efficient SIMDy instructions.
>
>> Not possible (for integers), unless you'd be ok with getting 
>> different
>> results at CT.
>
> You don't get different results at compile time if you are 
> explicit about wrapping.
>
>>> NUMBER f(NUMBER a, NUMBER b) ...
>>
>> Not sure what you mean here. 'f' is a perfectly fine existing
>> function, which is used at RT. It needs to be usable at CT as 
>> is.
>
> D claims to focus generic programming. So it should also 
> encourage pure functions that can be specified for floats, ints 
> and other numeric types that are subtypes of (true) reals in 
> the same clean definition.

I think it's a complete fantasy to think you can write generic 
code that will work for both floats and ints. The algorithms are 
completely different.

One of the simplest examples is that given float f;  int i;

(f + 1) and  (i +  1)  have totally different semantics.

There are no values of i for which i + 1 == i,
but if abs(f) > 1/real.epsilon, then f + 1 == f.

Likewise there is no value of i for which i != 0 && i+1 == 1,
but for any abs(f) < real.epsilon, f + 1 == 1.


> If you express the expression in a clean way to get down to the 
> actual (more limited type) then the optimizer sometimes can 
> pick an efficient sequence of instructions that might be a very 
> fast approximation if you reduce the precision sufficiently in 
> the end-result.

>
> To get there you need to differentiate between a truncating 
> division and a non-truncating division etc.

Well, it's not a small number of differences. Almost every 
operation is different. Maybe all of them. I can't actually think 
of a single operation where the semantics are the same for 
integers and floating point.

Negation comes close, but even then you have the special cases 
-0.0 and -(-int.max - 1).


> The philosophy behind generic programming and the requirements 
> for efficient generic programming is quite different from the 
> the machine-level hand optimizing philosophy of classic C, IMO.

I think that unfortunately, it's a quest that is doomed to fail. 
Producing generic code that works for both floats and ints is a 
fool's errand.