Operator precedence in Kotlin - Time & Space Complexity
We want to see how the order of operations affects how many steps a program takes.
How does the way Kotlin decides which operation to do first change the work done?
Analyze the time complexity of the following code snippet.
fun calculate(values: List): Int {
var result = 0
for (v in values) {
result += v * 2 + 3
}
return result
}
This code multiplies each number by 2, adds 3, and sums all results.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each item in the list once.
- How many times: Exactly once for each item in the input list.
Each new number adds a fixed amount of work: multiply, add, then add to total.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 times the fixed steps |
| 100 | About 100 times the fixed steps |
| 1000 | About 1000 times the fixed steps |
Pattern observation: The work grows directly with the number of items.
Time Complexity: O(n)
This means the time to finish grows in a straight line as the input list gets bigger.
[X] Wrong: "Changing the order of operations inside the loop changes how many times the loop runs."
[OK] Correct: The loop runs once per item no matter the order; operator precedence only changes how each item's calculation happens, not the number of times the loop runs.
Understanding how operator precedence affects calculations helps you explain how code runs step-by-step, a skill useful in many coding discussions.
"What if we added another loop inside the existing loop? How would the time complexity change?"
Practice
3 + 4 * 2?Solution
Step 1: Identify operators in the expression
The expression has addition (+) and multiplication (*).Step 2: Recall operator precedence rules
Multiplication (*) has higher precedence than addition (+), so it runs first.Final Answer:
Multiplication (*) -> Option AQuick Check:
Multiplication before addition = Multiplication (*) [OK]
- Thinking addition runs before multiplication
- Ignoring operator precedence
- Assuming left to right always applies
3 + 4 * 2 so that addition happens first?Solution
Step 1: Understand default precedence
Without parentheses, multiplication runs before addition.Step 2: Check which option forces addition first
(3 + 4) * 2 uses parentheses around (3 + 4), so addition happens before multiplication.Final Answer:
(3 + 4) * 2 -> Option BQuick Check:
Parentheses change order = (3 + 4) * 2 [OK]
- Ignoring parentheses effect
- Choosing expression without parentheses
- Assuming left to right overrides precedence
val result = 10 - 4 + 2 * 3 println(result)
Solution
Step 1: Apply operator precedence
Multiplication (*) runs first: 2 * 3 = 6.Step 2: Evaluate remaining expression left to right
10 - 4 + 6 = 6 + 6 = 12.Final Answer:
12 -> Option AQuick Check:
Multiplication before addition/subtraction = 12 [OK]
- Adding before multiplying
- Calculating left to right ignoring precedence
- Miscomputing subtraction and addition order
val x = 5 + 3 * 2 && true
What is the problem?
Solution
Step 1: Identify mixed types in expression
The expression mixes arithmetic (5 + 3 * 2) and boolean (&& true) without separation.Step 2: Understand Kotlin type rules
You cannot combine Int and Boolean directly without explicit logic or parentheses.Final Answer:
Cannot mix arithmetic and boolean operators without parentheses -> Option DQuick Check:
Mixing Int and Boolean needs care [OK]
- Thinking semicolon is missing
- Assuming && works with numbers
- Ignoring type mismatch errors
val result = true || false && false || true && false
What is the value of
result considering operator precedence?Solution
Step 1: Recall logical operator precedence
Logical AND (&&) has higher precedence than OR (||), so evaluate && first.Step 2: Evaluate all AND operations
false && false = false, true && false = false.Step 3: Replace and evaluate OR operations left to right
true || false || false = true || false = true.Final Answer:
true -> Option CQuick Check:
AND before OR, final result true [OK]
- Evaluating OR before AND
- Confusing operator precedence
- Assuming expression returns null or error
Ready to prove it?
Pass the test and this pattern moves unknown
