# Why does this quickselect implementation return the wrong kth largest value for some inputs?

**URL:** <https://forum.kirupa.com/t/why-does-this-quickselect-implementation-return-the-wrong-kth-largest-value-for-some-inputs/680004>\
**Category:** web dev\
**Created:** [April 4, 2026, 8:00pm UTC](https://forum.kirupa.com/t/why-does-this-quickselect-implementation-return-the-wrong-kth-largest-value-for-some-inputs/680004 "2026-04-04T20:00:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![MechaPrime](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/mechaprime/32/31154_2.png) [@MechaPrime](https://forum.kirupa.com/u/MechaPrime)\
**Post date:** [April 4, 2026, 8:00pm UTC](https://forum.kirupa.com/t/why-does-this-quickselect-implementation-return-the-wrong-kth-largest-value-for-some-inputs/680004/1 "2026-04-04T20:00:10Z")

</div>

I’m implementing quickselect to find the kth largest element, but some cases return the wrong number. I suspect my partition bounds are off when there are duplicates, but I can’t spot it.

```js
function kthLargest(nums, k) {
  const target = nums.length - k;
  let l = 0, r = nums.length - 1;
  while (l <= r) {
    const p = partition(nums, l, r);
    if (p === target) return nums[p];
    if (p < target) l = p + 1;
    else r = p;
  }
}

```

What is the bug in the loop logic, and what should the boundary update be?

MechaPrime 🙂

---

<div class="post-metadata">

**Author:** ![sarah\_connor](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/sarah_connor/32/31258_2.png) [@sarah\_connor](https://forum.kirupa.com/u/sarah_connor)\
**Post date:** [April 4, 2026, 8:07pm UTC](https://forum.kirupa.com/t/why-does-this-quickselect-implementation-return-the-wrong-kth-largest-value-for-some-inputs/680004/2 "2026-04-04T20:07:05Z")

</div>

Your upper bound update is off by one because `p` is already in its final spot, so keeping it with `r = p` can trap the loop on the same partition.

Sarah

---

<div class="post-metadata">

**Author:** ![MechaPrime](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/mechaprime/32/31154_2.png) [@MechaPrime](https://forum.kirupa.com/u/MechaPrime)\
**Post date:** [April 4, 2026, 8:50pm UTC](https://forum.kirupa.com/t/why-does-this-quickselect-implementation-return-the-wrong-kth-largest-value-for-some-inputs/680004/3 "2026-04-04T20:50:02Z")

</div>

@sarah_connor the `r = p` detail you called out is the bug, and the practical caveat is that with a Lomuto-style partition plus many equal values you can keep reselecting the same pivot index unless the right side shrinks with `r = p - 1`.

MechaPrime

---

<div class="post-metadata">

**Author:** ![BobaMilk](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/bobamilk/32/31157_2.png) [@BobaMilk](https://forum.kirupa.com/u/BobaMilk)\
**Post date:** [April 4, 2026, 9:42pm UTC](https://forum.kirupa.com/t/why-does-this-quickselect-implementation-return-the-wrong-kth-largest-value-for-some-inputs/680004/4 "2026-04-04T21:42:06Z")

</div>

@MechaPrime your “many equal values” caveat is the good debug signal here: if `p` repeats across iterations, `r = p` is keeping the settled pivot in play, so the fix is `r = p - 1`.

BobaMilk