'int' is enough for 'length' to migrate code from x86 to x64
via Digitalmars-d
digitalmars-d at puremagic.com
Mon Nov 24 09:55:04 PST 2014
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?
I'd say overflow/underflow means that the result is wrong. (Carry
is not overflow per se).
> 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.
>> 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.
More information about the Digitalmars-d
mailing list