Reverse Bits of a Number in DSA Rust - Time & Space Complexity
We want to understand how the time needed to reverse bits changes as the number size grows.
How does the number of steps grow when we reverse bits of a bigger number?
Analyze the time complexity of the following code snippet.
fn reverse_bits(mut n: u32) -> u32 {
let mut result = 0;
for _ in 0..32 {
result <<= 1;
result |= n & 1;
n >>= 1;
}
result
}
This code reverses the bits of a 32-bit unsigned number by shifting and collecting bits one by one.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The for-loop runs 32 times, once for each bit.
- How many times: Exactly 32 times, fixed for 32-bit numbers.
Since the loop runs once per bit, the time grows with the number of bits in the number.
| Input Size (bits) | Approx. Operations |
|---|---|
| 8 | 8 steps |
| 16 | 16 steps |
| 32 | 32 steps |
Pattern observation: The time grows linearly with the number of bits.
Time Complexity: O(n)
This means the time to reverse bits grows in a straight line with the number of bits.
[X] Wrong: "Reversing bits is constant time because the number size is fixed."
[OK] Correct: While fixed-size types like u32 have fixed steps, if the number size grows (like u64 or arbitrary length), time grows linearly with bits.
Understanding how bit operations scale helps you reason about low-level data tasks and optimize code in real projects.
What if we changed the input type from u32 to u64? How would the time complexity change?
Practice
Solution
Step 1: Understand bit representation
Bits are the 0s and 1s that represent a number in binary form.Step 2: Define reversing bits
Reversing bits means reading the bits from right to left instead of left to right, effectively flipping their order.Final Answer:
Flipping the order of bits from left to right -> Option CQuick Check:
Reverse bits = flip order [OK]
- Confusing reversing bits with bitwise NOT (inverting bits)
- Thinking reversing means shifting bits
- Assuming reversing adds or subtracts from the number
n?Solution
Step 1: Analyze bit reversal logic
We shift rev left by 1, add the least significant bit of n, then shift n right by 1.Step 2: Check each option
let mut rev = 0; for _ in 0..4 { rev <<= 1; rev |= n & 1; n >>= 1; } correctly does rev <<= 1; rev |= n & 1; n >>= 1; in loop. Others have wrong order or operations.Final Answer:
let mut rev = 0; for _ in 0..4 { rev <<= 1; rev |= n & 1; n >>= 1; } -> Option AQuick Check:
Shift rev left, add bit, shift n right [OK]
- Adding bit before shifting rev left
- Shifting n left instead of right
- Using addition instead of bitwise OR
fn reverse_bits(mut n: u8) -> u8 {
let mut rev = 0;
for _ in 0..8 {
rev <<= 1;
rev |= n & 1;
n >>= 1;
}
rev
}
fn main() {
let num = 13u8; // binary 00001101
println!("{}", reverse_bits(num));
}Solution
Step 1: Convert 13 to binary and reverse bits
13 in 8 bits is 00001101. Reversing bits gives 10110000.Step 2: Convert reversed bits back to decimal
10110000 binary equals 128+32+16=176 decimal.Final Answer:
176 -> Option AQuick Check:
00001101 reversed = 10110000 = 176 [OK]
- Not using 8 bits, missing leading zeros
- Confusing bit order or reversing incorrectly
- Calculating decimal value wrong
fn reverse_bits(mut n: u8) -> u8 {
let mut rev = 0;
for _ in 0..4 {
rev |= n & 1;
rev <<= 1;
n >>= 1;
}
rev
}Solution
Step 1: Analyze order of operations in loop
rev |= n & 1 adds bit, then rev <<= 1 shifts left, causing last bit to be zeroed out.Step 2: Correct order is shift rev left first, then add bit
Shifting rev left after adding bit loses the last bit added, so order must be reversed.Final Answer:
Shifting rev left after adding bit causes incorrect result -> Option BQuick Check:
Shift rev left before OR bit [OK]
- Adding bit before shifting rev left
- Loop count mismatch for bit size
- Shifting n left instead of right
Solution
Step 1: Know Rust's built-in bit reversal
Rust's primitive integer types have areverse_bits()method that reverses bits efficiently.Step 2: Compare options
Usen.reverse_bits()method directly on the number uses the built-in method directly, which is efficient and simple. Others are manual or incorrect methods.Final Answer:
Usen.reverse_bits()method directly on the number -> Option DQuick Check:
Use built-in reverse_bits() for efficiency [OK]
- Trying manual loops instead of built-in method
- Confusing byte swap with bit reversal
- Using string conversion which is inefficient
Ready to prove it?
Pass the test and this pattern moves unknown
