Data.List.maximumBy uses counter-intuitive ordering

[Theodore Lief Gannon]

Data.Ord.Down does roughly the same thing as your tiebreaker, I think.
(Different semantics, but sits in the same place.) Note that it has no need
to be a semigroup on its own!

On Fri, Jan 4, 2019, 7:41 AM Carter Schonwald <carter.schonwald at gmail.com
wrote:

> Does the inclusion of semi groups in base give another option? ?  There’s
> perfectly nice left and right biased min and max semigroups. Though I think
> we only provide one flavor each for min and max.
>
>
> Either it is useful to document the behavior as an artifact of current
> implementation but not commit to the exact same semantic in future versions
> so as not to preclude future innovations ?
>
>
> One fuzzy thought: it almost seems like there’s two semigroup structures
> in play here: the aggregation / aka min or max in this case, plus
> implicitly a second structure that provides the tie breaking structure in
> the case of equality , which is usually a left or right bias, but could be
> some other mechanism.  Is there a useful notion of a semigroup transformer
> or the like?
>
> On Thu, Jan 3, 2019 at 3:50 PM Ryan Reich <ryan.reich at gmail.com> wrote:
>
>> I think this is the right way to go: undefined when the maximum is
>> duplicated. It is not implausible, for instance, that someone's mental
>> model or even an alternate implementation of this function would, say, use
>> the quicksort-like binary search for the maximum, and that really could
>> give any of the options because quicksort is not stable.
>>
>> There is no right answer to this question and therefore no answer should
>> be demanded unless there is a compelling reason of efficiency.
>>
>> Definitely document this, though.
>>
>>
>> On Fri, Dec 28, 2018, 07:27 Eric Mertens <emertens at gmail.com wrote:
>>
>>> Hello,
>>>
>>> My opinion on this issue is that code should not be relying on the
>>> ordering of the choice made by maximumBy or minimumBy.
>>>
>>> If we changed something I’d prefer to document that it is undefined what
>>> element is chosen when two are considered equal by the comparison function.
>>>
>>> Code that relies on a particular earlier or later bias should use a
>>> function that makes it clear in the name that that’s what it’s doing.
>>> Readers should not be required to memorize the behavior of minimumBy or
>>> maximumBy in this regard to understand the code they are reading.
>>>
>>> Best regards,
>>> Eric
>>>
>>> > On Dec 28, 2018, at 7:18 AM, Johannes Waldmann <
>>> johannes.waldmann at htwk-leipzig.de> wrote:
>>> >
>>> > Dear all,
>>> >
>>> > this was brought up on the GHC tracker (not by me)
>>> >
>>> > https://ghc.haskell.org/trac/ghc/ticket/15921
>>> >
>>> > and it was suggested for discussion here.
>>> >
>>> > my summary: Data.List.maximumBy is right-biased,
>>> > minimumBy is left-biased, and none of this is documented.
>>> >
>>> > - J.W.
>>> >
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190108/2b9bce98/attachment.html>