Search
5 results for “binary-search”
Search results
Binary Search
Why bisect_left and bisect_right return different insertion points for the exact same value, and why binary search silently returns a wrong answer, not an error, the moment the input isn't actually sorted.
For a sorted list [1, 2, 2, 2, 3], what index does bisect_left(2) return versus bisect_right(2), and why are they different?
`bisect_left` returns 1, the insertion point before every existing 2, so inserting there keeps all 2s together immediately after it. `bisect_right` returns 4, the insertion point after every existing 2, keeping all 2s together immediately before it. They differ because they define the insertion point by a different partition rule, `bisect_left` guarantees everything before the returned index is strictly less than the target, `bisect_right` guarantees everything before the returned index is less than or equal to it, so the choice determines whether a new equal-valued element gets inserted before or after existing equal elements, not just where "some 2" is found.
Why does binary search require the input to already be sorted, and what actually happens if you run it on unsorted data?
Binary search's core logic is comparing the target against a midpoint and eliminating the entire half that can't possibly contain it, an elimination step that's only valid if elements are ordered, so everything below the midpoint really is smaller and everything above really is larger. Run it on unsorted data and there's no error or exception, the algorithm has no way to detect the invariant is broken, it just keeps halving the search space based on comparisons that no longer imply anything real, and returns an insertion point or "not found" result that has no actual relationship to whether or where the target exists in the list.
Why is binary search O(log n) instead of O(n), and what specifically has to be true about the data structure for that to hold?
Each comparison eliminates half of the remaining search space, so after k comparisons only n/2^k elements remain to check, meaning the search terminates once 2^k ≥ n, k ≈ log2(n) comparisons, exponentially fewer than checking every element one at a time. That guarantee depends entirely on being able to jump directly to a midpoint in constant time, which is true for an array or list with O(1) random access, but not for a data structure like a linked list where reaching the "middle" element itself takes O(n) time, on a linked list, binary search's comparison-count advantage is real but gets erased by the cost of just navigating there.
A custom dropdown built entirely from styled divs passes a visual design review. What is likely still broken for a keyboard-only or screen-reader user, and why doesn't looking right catch it?
Without the correct ARIA roles/states (or, better, a native `<select>`), a div-based dropdown typically has no way to be reached or operated via keyboard alone (no built-in Tab/Enter/Arrow-key handling), and a screen reader has no semantic information telling it "this is a dropdown, it is currently closed, here are its options," so it may announce nothing meaningful at all. A purely visual review can't catch this because the div looks and behaves correctly with a mouse, the missing behavior only surfaces via keyboard navigation or assistive technology, which is exactly why accessibility has to be tested directly with a keyboard and a screen reader, not inferred from how a component looks.