Arithmetic operators in Rust - Time & Space Complexity
We want to see how the time needed to do arithmetic operations changes as the numbers get bigger.
How does the cost grow when we do simple math in code?
Analyze the time complexity of the following code snippet.
fn sum_numbers(numbers: &[i32]) -> i32 {
let mut total = 0;
for &num in numbers {
total += num;
}
total
}
This code adds up all numbers in a list and returns the total sum.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Adding each number to the total.
- How many times: Once for every number in the list.
As the list gets longer, the number of additions grows the same way.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 additions |
| 100 | 100 additions |
| 1000 | 1000 additions |
Pattern observation: The work grows directly with the number of items.
Time Complexity: O(n)
This means the time to add numbers grows in a straight line as the list gets bigger.
[X] Wrong: "Adding numbers is always instant, no matter how many there are."
[OK] Correct: Each number must be added one by one, so more numbers mean more work.
Understanding how simple math operations scale helps you explain how your code handles bigger data smoothly.
"What if we used multiplication instead of addition for each number? How would the time complexity change?"
Practice
Solution
Step 1: Understand the meaning of each operator
The / operator divides, * multiplies, - subtracts, and % gives the remainder after division.Step 2: Identify the operator for remainder
The % operator returns the remainder when one number is divided by another.Final Answer:
The % operator -> Option DQuick Check:
Remainder operator = % [OK]
- Confusing / with %, thinking / gives remainder
- Using * or - for remainder
- Mixing up operator symbols
a and b in Rust?Solution
Step 1: Recall Rust arithmetic syntax
Rust uses * for multiplication, not x, ., or &.Step 2: Confirm correct operator
The expressiona * bcorrectly multiplies a and b.Final Answer:
a * b -> Option AQuick Check:
Multiplication operator = * [OK]
- Using x instead of *
- Using . or & which are not arithmetic
- Confusing syntax with other languages
let x = 10;
let y = 3;
let result = x / y;
println!("{}", result);Solution
Step 1: Understand integer division in Rust
Both x and y are integers, so x / y performs integer division, dropping decimals.Step 2: Calculate integer division
10 divided by 3 is 3.3333, but integer division truncates to 3.Final Answer:
3 -> Option CQuick Check:
Integer division truncates decimals = 3 [OK]
- Expecting decimal result with integer division
- Confusing integer and float division
- Assuming syntax error due to println!
let a = 5;
let b = 2;
let c = a / b.0;
println!("{}", c);Solution
Step 1: Analyze the expression a / b.0
The code tries to access .0 on b, which is an integer, not a tuple or struct.Step 2: Understand why .0 causes error
Only tuples or structs have fields like .0; integers do not, so this causes a compile error.Final Answer:
Using .0 on integer causes error -> Option BQuick Check:
Integer has no .0 field = error [OK]
- Thinking / is invalid operator
- Missing semicolon causes error
- Assuming variables are undeclared
a and b in Rust and get a float result. Which code snippet correctly does this?Solution
Step 1: Understand type conversion for float division
To get a float result, convert integers to float before division.Step 2: Check each option for correct syntax and types
let avg = (a + b) / 2; does integer division, no float result. let avg = (a + b) as f64 / 2.0; converts sum to f64, divides by 2.0 (float), correct. let avg = (a + b) / 2.0; divides integer sum by float 2.0 without conversion, invalid. let avg = (a + b) / 2 as f64; tries to cast 2 to f64 before division (due to `as` precedence), invalid.Final Answer:
let avg = (a + b) as f64 / 2.0; -> Option AQuick Check:
Convert to float before dividing by float [OK]
- Dividing integers by float without cast
- Casting after division
- Using integer division expecting float result
Ready to prove it?
Pass the test and this pattern moves unknown
