> **Problem**: https://leetcode.com/problems/find-peak-element/submissions/ # Comments on the solution We can use two different approach, that are asymptotically equivalent in terms of space complexity, but in the reality the second one is more efficient, as we can see in the leetcode results ## First approach ```rust fn find_peak_element(nums: Vec) -> i32 { let (mut left, mut right) = (0, nums.len() - 1); while left) -> i32 { return Self::find_peak_element_recursive(&nums, 0, nums.len() - 1) as i32; } fn find_peak_element_recursive(nums: &Vec, left: usize, right: usize) -> usize { if left == right { return left; } let mid = left + (right - left) / 2; if nums[mid] < nums[mid + 1] { return Self::find_peak_element_recursive(nums, mid + 1, right); } else { return Self::find_peak_element_recursive(nums, left, mid); } } ``` This implementation uses a recursive helper function that takes the input vector, the left and right indices of the current subarray being searched. The helper function returns the index of the peak element. The main function simply calls the helper function with the initial left and right indices. This implementation has the same time complexity as the previous one, but may use less memory due to the reduced number of variables used. However, the difference in memory usage is negligible and I did this just for obtaining an higher score in leetcode ![](https://i.imgur.com/5LfVVJu.png) ### Complexity - **Time complexity**: `O(log(n))` because we are doing a binary search - **Space complexity**: `O(1)` because we are not using any extra space