First of all, if you are talking about console output, don't forget to explicitly tell the
binary() function to display all the digits. (presumably 32, if you use int)
Now, regarding shift- and rotation behaviour, let me google that for you ;)
Since Processing secretly is just a less verbose Java, looking up how shifts work in Java should answer your problem:
In
Java
, all integer types are signed, and the "
<<
" and "
>>
" operators perform arithmetic shifts. Java adds the operator "
>>>
" to perform logical right shifts, but because the logical and arithmetic left-shift operations are identical, there is no "
<<<
" operator in Java. These general rules are affected in several ways by the default
type promotions
; for example, because the eight-bit type
byte
is promoted to
int
in shift-expressions,
the expression "
b >>> 2
" effectively performs an arithmetic shift of the byte value
b
instead of a logical shift. Such effects can be mitigated by judicious use of
casts
or
bitmasks
; for example, "
(b & 0xFF) >>> 2
" effectively results in a logical shift.
Also, regarding rotation, you can turn that into a simple one-liner:
For some reason, this ROR seems much more readable to me:
(i << (32-n)) | (i >>> n)
I think because it deals with the left most bit first, and I think left to
right. "Left" is highbit, because of the way you write down binary on
paper.
Making ROL:
(i << n) | (i >>> (32-n))
This is of course assuming you use all 32 bits of the integer. If you want to use less bits, you need an extra bitmask. So from the top of my head:
( ( i << (number of bits-n ) ) | ( i >>> n ) ) & bitmask to mask down to number of bits //ROR
( ( i << n ) | ( ( i >>> (
number of bits-n ) ) &
bitmask to mask out the high bits ) ) &
bitmask to mask down to number of bits //ROL
EDIT: removed bug from ROL.
