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.
