[GHC] #15921: Foldable.maximumBy uses counter-intuitive ordering
#15921: Foldable.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: List | Operating System: Unknown/Multiple maximumBy minimumBy | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)] }}} What do you expect the outcome to be? All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the ''last'' occurrence of a 'maximum' element) is kept. Furthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request: - If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it. - If its behaviour is intentionally the opposite, this should be specified in the documentation. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This should be discussed at libraries@haskell.org first. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Documentation already says "the (comparison) function is assumed to define a total ordering". The function `comparing snd` does not. It defines a relation that is total, transitive, reflexive, but not antisymmetric. Then all bets are off, at least officially. There are local `minBy/maxBy` functions in the implementation {{{ min' x y = case cmp x y of GT -> y _ -> x max' x y = case cmp x y of GT -> x _ -> y }}} that treat the `EQ` case differently. That does not feel consistent with the "laws for `Ord` that are expected to hold" (where `EQ` would always select the first argument) {{{ max x y == if x >= y then x else y = True min x y == if x <= y then x else y = True }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
There are local minBy/maxBy functions in the implementation that treat
#15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by qqwy): the EQ case differently. That does not feel consistent with the "laws for Ord that are expected to hold" (where EQ would always select the first argument) This is what the problem distills do, and what I feel should be changed (instead making the implementations of the `min'` and `max'` local to `minBy/maxBy` align with the behaviour of the public `min` and `max`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Replying to [comment:3 osa1]:
This should be discussed at libraries@haskell.org first.
I just posted https://mail.haskell.org/pipermail/libraries/2018-December/029299.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC