Email list hosting service & mailing list manager

Twos complement assumption, other issues Laura Dickey (15 Jan 2005 17:44 UTC)
Re: Twos complement assumption, other issues Aubrey Jaffer (27 Jan 2005 19:00 UTC)
Re: Twos complement assumption, other issues Bradd W. Szonye (27 Jan 2005 19:04 UTC)
Re: Twos complement assumption, other issues Aubrey Jaffer (29 Jan 2005 00:53 UTC)

Re: Twos complement assumption, other issues Aubrey Jaffer 27 Jan 2005 19:00 UTC

 | From: "Scott G. Miller" <xxxxxx@gmail.com>
 | Date: Sat, 15 Jan 2005 18:44:40 +0100
 |
 | The SRFI assumes that integers are represented in two's complement
 | form, and states as such.  Since R5RS makes no such assumption,
 | perhaps it would be worthwhile to have a line or two (maybe in the
 | implementation or rational sections) noting that the functions can
 | be implemented by converting to/from twos complement as necessary,
 | but that the majority of implementations already treat integers
 | this way.

I have added a section to the Rationale:

 Bits and Complements

 A bit-index in these descriptions is nonnegative with the least
 significant bit at index 0.

 The reference implementation is written using only Scheme integer
 operations.  Thus the only exposure of the underlying representation is
 in the ranges of fixnums.

 The complement describes the representation of negative integers.
 With one's-complement fixnums, the range of integers is -(2^n) to 2^n,
 and there are two possible representations of 0. With
 two's-complement fixnums, the range of integers is -(1+2^n) to 2^n.

 Since we treat integers as having two's-complement negations, the
 two's-complement of an integer is its negation.  The one's-complement
 of an integer is computed by lognot:

 (define (lognot n) (- -1 n))

 A positive integer has a finite number of "1" bits. A negative integer
 has a finite number of "0" bits.

 | In other discussions, I also prefer SRFI-33's names (and title!),

I have changed the title to "Integers as Bits".

 | as both follow Scheme's naming tradition of preferring clarity and
 | consistency to succinctness.

All the corresponding SRFI-33 names are now included.

 | Finally, I'm not a mathematician, but including Gray codes in what
 | is otherwise a general SRFI seems a bit odd.

The Gray-code functions are removed.