Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

How to force binary bit representation of a number, so BitNot does yield the 1s-complement?

BitNot[n] turns ones into zeros and vice versa in the binary bit representation of n.

I was unable so far to produce a number which Mathematica accepts as a binary bit representation. Is there a way (like casting) to convince Mathematica that some number has to be treated as a binary bit representation?

Any help appreciated.

share|improve this question
No I don't. It says that in the second phrase, but no "both". What do you expect from a Boolean operation 'Not'? Documentation says that for integers. So sizeof(int) = 4; on 64-bit. There is a clear distinction between 4-byte boundary and binary bit representation. If I pass an unsigned char it's a byte and somewhat really different from a char or, so you will, an integer, which is a 4* signed char and not 4 * unsigned char. There is exactly that distinction. –  Stefan Jan 24 '13 at 19:49
add comment

1 Answer 1

Why this happens

The documentation states

Integers are assumed to be represented in two's complement form, with an unlimited number of digits, so that BitNot[n] is simply equivalent to $-1-n$.

So Mathematica does not assume a fixed number of binary digits (you can't assume your number to be 64 bit long or 32 bit long). It always takes the exact number of bits necessary to represent the number in two's complement form.


If you start with $n=5$, the binary representation is $0101_2$ because 4 bits are the minimal number needed to represent 5 in this form. The leading 0 is needed for the sign. The negation of this is $1010_2 = -2^4 + 10 = -6$.

How to achieve what you want

One way is to convert the number to a list of digits and work with that:

not[lst_] := 1 - lst
not@IntegerDigits[5, 2]

The third argument of IntegerDigits controls the number of digits you need. FromDigits converts back to a number.

share|improve this answer
thank for your clear answer. That is exactly the behavior I was wondering about, this best fit representation of a number. But that does not answer my question if there is a way to force byte boundaries so that the "...turns ones into zeros.." is not falsified? The first statement does promise a 1s'complement. –  Stefan Jan 24 '13 at 20:05
@Stefan Did you see my edit? One way is to work with lists of digits. Unfortunately I don't think it's possible to force BitNot to do what you need. –  Szabolcs Jan 24 '13 at 20:07
@Stefan Note that working with lists of integers and arithmetic operations (e.g. "and" would be list1*list2, "or" would be Clip[list1+list2]) will be much faster than working with lists of True and False. –  Szabolcs Jan 24 '13 at 20:12
@Stefan "...turns ones into zeros.." is never falsified, and it does provide a 1's complement as is shown in Szabolcs example 0101->1010. What would you expect 0101 to be turned into? I think you're confusion is with what those steams of bits are interpreted as when you convert them back into numbers. Did you look at the wiki page both me and Szabolcs linked to? –  jVincent Jan 24 '13 at 20:22
The problem with it being a Not operation on bits is that that is not well defined unless you also specify the total number of bits (to allow for 0's as leading bits). –  Daniel Lichtblau Jan 24 '13 at 21:05
show 1 more comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.