'int' is enough for 'length' to migrate code from x86 to x64

[Matthias Bentrup via Digitalmars-d]

On Monday, 24 November 2014 at 17:55:06 UTC, Ola Fosheim Grøstad
wrote:
> On Monday, 24 November 2014 at 17:12:31 UTC, Matthias Bentrup 
> wrote:
>> Overflow is part of modular arithmetic. However, there is no
>> signed and unsigned modular arithmetic, or, more precisely, 
>> they
>> are the same.
>
> Would you say that a phase that goes from 0…2pi overflows? Does 
> polar coordinates overflow once every turn?
>

No, sin and cos are periodic functions, but that doesn't mean
their arguments are modular. sin 4pi is well defined by e.g. the
taylor expansion of sin without any modular arithmetic at all.

> I'd say overflow/underflow means that the result is wrong. 
> (Carry is not overflow per se).
>

There is no right or wrong in Mathematics, only true and false.
The result of modular addition with overflow is not wrong, it is
just different than the result of integer addition.

>> Or you can use some other order preserving arithmetic (e.g.
>> saturating to min/max values), but that breaks the arithmetic
>> laws.
>
> I don't think it breaks them, but I think a system language 
> would be better off by having explicit operators for 
> alternative edge-case handling on a bit-fiddling type. E.g.:
>
> a + b as regular addition
> a (+) b as modulo arithmetic addition
> a [+] b as clamped (saturating) addition
>
> The bad behaviour of C-like languages is the implicit coercion 
> to/from a bit-fiddling type. The bit-fiddling should be 
> contained in expression where the programmer by choosing the 
> type says "I am gonna do tricky bit hacks here". Just casting 
> to uint does not convey that message in a clear manner.
>

Agreed, though I don't like the explosion of new operators. I'd
prefer the C# syntax like check(<expression>), wrap(expression),
saturate(expression).

>>> A solid solution solution is to provide «As if Infinitely 
>>> Ranged Integer Model» where the compiler figures out how 
>>> large integers are needed for computation and then does 
>>> overflow detection when you truncate for storage:
>>>
>>> http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
>>
>> You could just as well use a library like GMP.
>
> I think the point with having compiler support is to retain 
> most optimizations. The compiler select the most efficient 
> representation based on the needed headroom and makes sure that 
> overflow is recorded so that you can eventually respond to it.
>
> If you couple AIR with constrained integer types, which Pascal 
> and Ada has, then it can be very efficient in many cases.

And can fail spectacularly in others. The compiler always has to
prepare for the worst case, i.e. the largest integer size
possible, while in practice you may need that only for a few
extreme cases.