From: helfper@...
Date: 2015-08-20T22:30:14+00:00
Subject: [ruby-core:70484] [Ruby trunk - Bug #11471] min, min_by, max, max_by with optional parameter return a wrong value

Issue #11471 has been updated by Helder Pereira.


Yes, I was wrong. I missed this check in "nmin_filter":

~~~
    if (data->curlen <= data->n)
        return;
~~~

Which means that your patch will never execute the "nmin_filter" (that is where the bug lays) until it is called in "nmin_run", and consequently the buffer will grow until the size of the original array (and will not be proportionally to the number of elements we want anymore).

Because your patch makes this piece of code in "nmin_i" useless:

~~~
    if (data->curlen == data->bufmax) {
        nmin_filter(data);
    }
~~~

----------------------------------------
Bug #11471: min, min_by, max, max_by with optional parameter return a wrong value
https://bugs.ruby-lang.org/issues/11471#change-53887

* Author: Tsuyoshi Sawada
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
This is reported in StackOverflow: http://stackoverflow.com/questions/32121749/why-20-13-14-min2-13-20. Sometimes `min`, `min_by`, `max`, `max_by` with an optional parameter return a wrong value.

    [20, 32, 32, 21, 30, 25, 29, 13, 14].min(2) # => [13, 20]
    [20, 32, 32, 21, 30, 25, 29, 13, 14].min_by(2, &:itself) # => [13, 20]
    [0, 0, 0, 0, 0, 0, 1, 3, 2].max(2) # => [3, 1]
    [0, 0, 0, 0, 0, 0, 1, 3, 2].max_by(2, &:itself) # => [3, 1]

---Files--------------------------------
enum_bug_fix.patch (2.05 KB)
enum_bug_fix.patch (2.1 KB)


-- 
https://bugs.ruby-lang.org/