andrewcoppin at btinternet.com
Fri Aug 26 19:24:37 CEST 2011
On 26/08/2011 02:40 AM, Daniel Peebles wrote:
> And as Daniel mentioned earlier, it's not at all obvious what we mean by
> "bits used" when it comes to negative numbers.
I guess part of the problem is that the documentation asserts that
bitSize will never depend on its argument. (So would will write things
like "bitSize undefined :: ThreadID" or similar.)
I can think of several possible results one might want from a bit size
1. The number of bits of precision which will be kept for values of this
type. (For Word16, this is 16. For Integer, this is [almost] infinity.)
2. The amount of RAM that this value is using up. (But that would surely
be measured in bytes, not bits. And processor registors make the picture
3. The bit count to the most significant bit, ignoring sign.
4. The bit count to the sign bit.
Currently, bitSize implements #1. I'm not especially interested in #2. I
would usually want #3 or #4.
Consider the case of 123 (decimal). The 2s complement representation of
The 2s complement representation of -123 is
For query #3, I would expect both +123 and -123 to yield 7. For query
#4, I would expect both to yield 8. (Since if you truncate both of those
strings to 8 bits, then the positive value starts with 0, and the
negative one start with 1.)
Then of course, there's the difference between "count of the bits" and
"bit index", which one might expect to be zero-based. (So that the Nth
bit represents 2^N.)
More information about the Haskell-Cafe