svn commit: r300332 - in head/sys: amd64/amd64 i386/i386

Bruce Evans brde at optusnet.com.au
Sun May 22 00:58:17 UTC 2016


On Sat, 21 May 2016, Conrad Meyer wrote:

> On Fri, May 20, 2016 at 9:13 PM, Bruce Evans <brde at optusnet.com.au> wrote:
>> On Fri, 20 May 2016, Conrad Meyer wrote:
>>
>>> On Fri, May 20, 2016 at 6:10 PM, Bruce Evans <brde at optusnet.com.au> wrote:
>>>>
>>>>
>>>> Signed integers are easier to understand provided calculations with them
>>>> don't overflow.
>>>
>>> How?
>>
>> For the same reasons as in applying mathematics.  Applying mathematics
>> ...
>> Ordinary (real) numbers (including negative ones) also have good ordering
>> properties for all operations.
>>
>> Computer arithmetic can't represent all ordinary numbers, but gets closest
>> by representing ordinary integers as C signed integers perfectly when no
>> overflow occurs.
>>
>> By using C unsigned integers unnecessarily, you throw out invention of
>> negative numbers and might have to work with the unfamiliar and badly
>> behaved ordering on them.  C programmers have some experience with this
>> ordering, but apparently not enough to usually avoid bugs.
>> ...
> Thanks for explaining.
>
> Can you explain a little bit about the badly behaved ordering of
> unsigned integers?  I am not familiar with that.

The strongest ordering properties for real numbers depend on the existence
of negative numbers (and zero).  E.g., x >= y if and only if x - y >= 0.
To apply that, you need the more basic property that the ordering keeps
negative numbers separate from strictly positive numbers and zero.

Without negative numbers, we can hope for weaker properties.  One is
that x1 <= x2 implies x1 + y <= x2 + y.  The is true for C signed and
unsigned integers if there is no overflow, but for the unsigned case
overflow is often considered normal and is technically not described
as overflow.

Ordering for multiplication breaks down similarly.

Division has complications before considering ordering, so don't
consider it.

Ordering for subtraction breaks down more than for addition, despite
it working perfectly as a (reversible) algebraic operator for the
unsigned case.  Overflow causes problems as usual, and subtraction
of unsigned values x - y always "overflows" if y is larger.  Signed
integers work especially well for subtraction if the operands are
non-negative, since then it never overflows.

Bruce


More information about the svn-src-head mailing list