213 posts
Posted 10 April 2015 - 11:47 AM
So for most of the bit functions they compare the logical number of two numbers you compare for example bit.bxor(0,15) would return 0 since 15 is 4 bits so it compares their first 4 bits as expected however the not function evaluates the given number as a 32 bit integer so no matter what number you put in it you get a ridiculously large seemingly unusable number. What is the practicality or reason for the function running differently from any other bit functions?
7083 posts
Location
Tasmania (AU)
Posted 10 April 2015 - 12:31 PM
bit.xor() isn't just checking "the first four bits". It's checking all those provided to it, same as bnot. The functions are behaving the same in that regard.
If you only want to invert a certain amount of bits, then bit.band() your result.
213 posts
Posted 10 April 2015 - 12:48 PM
Right I just woke up when I was testing this and temporarily forgot logic :P/> ignore me I just got shocked by the massive output at 3 in the morning. Currently though I'm just doing 15-number instead since that will always be equal to the inverted number bitwise if it's 4 bits or less
355 posts
Location
Germany
Posted 10 April 2015 - 12:49 PM
To illustrate Bomb Blokes answere
0...0000011 = 3
XOR
0...0001110 = 14
=
0...0001101 = 13
^^^^^^^^^^^ affects all bits, you always provide a ton of zeros to the function, when you chose small numbers.
NOT
0...0000011 = 3
=
1...1111100 = the large number you are talking about
The "
practicality" it always uses 32 bits is, that it doesn't take longer to execute than on a specified set of bits and elegantly escapes all the problems you get when using different amounts of bits.
Also: How would you provide your functions a zero at the beginning? You wouldn't be able to do it, since your misconception assumes, that the highest bit set to 1 defines the length of your bit chain.