About Complements.

firstly when you are dealing with numbers and their representations,
you have to decide on the size of the format to allow.
for instance if you have a 4 bit format just for decimal integers,
then the number 1 has the representation 0001, and the negative, -1
in 1's complement has the representation 1110.
Note, in 1's complement, 0 has two representations, 0000 and 1111.
how does one verify that one has the correct one's complement
representation for the negative of a number ?
take the number, say +1 and take the 1's complement repr. of the negative,
i.e. -1 in this case, and add the two according to the rules of addition
of 1's complement numbers.
so for instance here we have :
  0001
+ 1110
------
  1111

which is the representation for 0 in 1's complement (or rather, one of the
representations of 0 in 1's complement) so we are fine.

The representation for 1's complement for negative decimal numbers (which
aren't integers) is a bit complicated.

The problem essentially stems from the multiple representations for 0.

Say, for the time being, that the format size that we use is l (ell).
that is, l bits are allotted to the integral part of any number.
(that is, in the examples you give, as in the relevant part of the book,
l = 4).

We saw, that for integers, the 1's complement is easy to get, and it is
just that, (for the sake of exposition, we just let l = 4 here)
so, l=4 implies we can use 3 bits for the actual number, and the MSB
is the sign bit. so, that means, the numbers that can be represented
in the 1's complement using just 4 bits, are -7 to +7 (all in all, 15
numbers). suppose we have to get the representation for -5. we know the
representation for +5 (0101) but lets try to forget that for the time.
what we do is ... do : 7 + (-5) , get 2, get the unsigned 3 bit
representation for 2 (010) and prefix it with a sign bit, 1.
hence the representation for -5 becomes 1010.  note that this is just the
1's complemented version for 0101.
what are we doing here ? we are just trying to see what it is that 1's
complement is actually doing. getting another handle on the 1's complement
other than the usual "complement each bit" thingy.
how does this help ? this seems a bit more complicated than the
"complement each bit" procedure. of course. but thats only for integers.
look at decimal fractions.
say you have to represent -2.5. we know that the repr. for 2.5 is
0010.1 . how do we get -2.5 ... the usual complement each bit doesn't work
any more, so what we rather use is the other method.... subtract from 7,
and then get (7-2.5 = 4.5) get the unsigned repr. for 4.5 and prefix it
with a 1, as the sign bit.
thus, 4.5 = 100.1 and  -2.5 in the 1's complement...  is hence,
1100.1 .
Why can't we complement each bit, as we used to do before, for decimal
integers?? here's why.
say, 2.5 = 0010.1 so ... complementing each bit, INCLUDING the ones after
the decimal gives us...  1101.0 ! that is, we have 2.5 which is a non
integer, so also is its negative, but when we do the "complement each bit"
procedure, we get a number thus which "seems" to be integral : has .0
after the decimal point.
hence, we cant use the complement each bit thing here.
How about ... the representation of 0.0 .. thats easy, its just
0000.0 . but no, 0 has two representations, so its also 1111.0 !
ok, but what about the representation of 0.5  : its 0000.1 and ALSO
1111.1 ! thats where 1's complement causes all the problems... two many
representations for these numbers (0.0 , 0.5 , 0.25 and all ).
what about -0.5 ... we have to follow the other procedure. subtract from
7. get 6.5 . represent 6.5 using three bits for the integer part.
that is, 110.1 .. now prefix a sign bit and thus, you have
1110.1 =  -0.5 .
So far, so good. We can try out a few additions to see if everything's ok.
lets try adding +5.5 and -2.5  :

+5.5 : 0101.1
-2.5 : 1100.1   [from above]
-------------
Add : 10010.0
      ^
    strip this overcarry away and bring it to the front, just before the
decimal point, as described in the book, pp.67-68.
          1.0
-------------
       0011.0
       = +3.0 as things ought to be.

What about a more mundane addition, +5.5 and -5.5 ?

+5.5 : 0101.1
-5.5 : 1001.1
-------------
Add :  1111.0  = -0.0


I hope this helps to clarify at least part of the issue.
because we use 4 bits, the maximum "integer" we can represent using this
being 7, we subtract it from 7 always to get the representation of
negative numbers.
say for instance, we had 5 bits allowed for every integer. then we would
have to subtract it from 2^4 - 1 = 15.