Inconsistent Enumerable#minmax
behavior when an element is not comparable
#8440
Labels
good first issue
This is an issue suited for newcomers to become aquianted with working on the codebase.
help wanted
This issue is generally accepted and needs someone to pick it up
kind:bug
A bug in the code. Does not apply to documentation, specs, etc.
topic:stdlib:collection
Summary
The current (0.31.1) implementation of
Enumerable#minmax
does not define any behavior when theEnumerable
contains an element which is not comparable with other elements. Consequently, some rather inconsistent results can occur depending on the ordering of elements in theEnumerable
. Since the ordering of anEnumerable
should not have any effect on the minimum or maximum element, this inconsistency appears erroneous, and I believe it should be fixed. While I have not verified, this inconsistency is likely an issue with all variants of#min
and#max
as well.Example
I encountered this issue specifically in the context of trying to extract a minimum or maximum value from an
Enumerable(Float64)
which containedFloat64::NAN
values. It would seem that whenever the first element of anEnumerable
isNaN
, the result of#minmax
will always be{NaN, NaN}
regardless of any other non-NaN
elements. In any other case, the result of#minmax
will be as expected, with allNaN
elements ignored.Possible Resolutions
In looking into this issue, I noticed that
Enumerable#minmax
only ever uses<
and>
between elements and never seems to have been updated to use the partial comparability of<=>
. I think it would be best to follow the precedent of #6611 and reworkEnumerable#min
,Enumerable#max
, andEnumerable#minmax
to use<=>
and raise when an element is not comparable.The text was updated successfully, but these errors were encountered: