# [Haskell-cafe] abs minBound < (0 :: Int) && negate minBound == (minBound :: Int)

Kyle Miller kmill31415 at gmail.com
Mon Aug 19 17:43:05 CEST 2013

```On Sun, Aug 18, 2013 at 8:04 PM, Richard A. O'Keefe <ok at cs.otago.ac.nz>wrote:

> The argument for twos-complement, which always puzzled me, is that the
> other
> systems have two ways to represent zero.  I never found this to be a
> problem,
> not even for bitwise operations, on the B6700.  I *did* find "abs x < 0"
> succeeding to be a pain in the posterior.  (The B6700 had two different
> tests:
> 'are these two numbers equal' and 'are these two bit patterns equal'.)

I think a better argument for twos complement is that you're just doing all
of your computations modulo 2^n (where n is 32 or 64 or whatever), and
addition and multiplication work as expected modulo anything.  The idea of
negative and positive in a system like this is artificial, though.  The
standard convention follows from the observation that 0-1 should be -1, and
if you use the hardware that is for positive numbers, and assume that you
can always carry another 1 for the highest order bit, then 0-1 is
1111...111.  It's not that 2^n - 1 is actually -1, but that it acts like a
-1 would act.  It's only by convention that numbers which begin with a 1
are considered to be negative (that, and Intel has special hardware for
detecting if a number has its leading 1 set).

However, we could adopt the convention that you need two leading ones to
make a negative number, and everything would work out, except for the
inequality testing built into the CPU.  This would give us a lot more
positive numbers, and then abs wouldn't have this problem :-)

Or, three other options: 1) make MIN_INT outside the domain of abs, 2) make
the range of abs be some unsigned int type, or 3) use Integer (i.e., use a
type which actually represents integers rather than a type which can only
handle small integers).

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...