Proposal: Add `maxOn` and `minOn` functions to Data.Ord - Libraries - Haskell.org

newer
Discussion: Add total indexing...

Proposal: Add `maxOn` and `minOn` functions to Data.Ord

older
Proposal: Add insertAt to...

Daniel Díaz Casanueva

27 May 2016 27 May '16

2:51 p.m.

I think these are useful in general, and that they would make a good addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions: ``` minOn :: Ord b => (a -> b) -> a -> a -> a minOn f x y = case comparing f x y of LT -> x _ -> y maxOn :: Ord b => (a -> b) -> a -> a -> a maxOn f x y = case comparing f x y of GT -> x _ -> y ``` These don't need to be the exact definitions, but they convey the semantics I'm looking for.

Attachments:

attachment.html (text/html — 724 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Edward Kmett

27 May 27 May

3:02 p.m.

Note: in general we have chosen to supply By methods, rather than On methods, because he on combinator can be used to get one in terms of the other. We explicitly added sortOn because it can use a Schwartzian transform to be more efficient than sortBy (comparing `on` f). These don't have direct analogues there, however. So that usual argument against adding these sorts of methods doesn't hold up. One thing of note is that what you are asking for here is usually called argmin and argmax. Perhaps consistency with the rest of mathematics should trump consistency with sortOn. IIRC, We already have Arg in Data.Semigroup for use with the Min and Max semigroups for this purpose, so such naming would fit. -Edward

On May 27, 2016, at 2:51 PM, Daniel Díaz Casanueva wrote:

I think these are useful in general, and that they would make a good addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions:

``` minOn :: Ord b => (a -> b) -> a -> a -> a minOn f x y = case comparing f x y of LT -> x _ -> y

maxOn :: Ord b => (a -> b) -> a -> a -> a maxOn f x y = case comparing f x y of GT -> x _ -> y ```

These don't need to be the exact definitions, but they convey the semantics I'm looking for. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Evan Laforge

4:04 p.m.

On Fri, May 27, 2016 at 12:02 PM, Edward Kmett wrote:

Note: in general we have chosen to supply By methods, rather than On methods, because he on combinator can be used to get one in terms of the other. We explicitly added sortOn because it can use a Schwartzian transform to be more efficient than sortBy (comparing `on` f).

I've noticed that I've needed the "by" only very rarely, while I use "on" variants almost every time. Specifically, for sorting, grouping by key, max, min, and total versions of maximum and minimum, all extremely useful. I don't mind their absence from Data.List because I have them all in a local library and I tend to think a local library makes everyone happier than trying to put the union of everything everyone wants in the standard library. But I wonder if others have the same experience, and if it isn't one of those cases where haskell prioritized more general over more convenient. I also like the On suffix because it can be applied universally to all functions that take a key function. But anyway, there is also a data-ordlist package out there that has a bunch of utilities along those lines, perhaps its maintainer would be receptive to maxOn and minOn.

Reply

Sign in to reply online Use email software

Daniel Díaz Casanueva

4:24 p.m.

But anyway, there is also a data-ordlist package out there that has a bunch of utilities along those lines, perhaps its maintainer would be receptive to maxOn and minOn.

Except that `maxOn` and `minOn` are not related to lists, and that package is a set of functions related to ordered lists.

Reply

Sign in to reply online Use email software

Daniel Díaz Casanueva

4:30 p.m.

On Fri, May 27, 2016 at 3:02 PM, Edward Kmett wrote:

Note: in general we have chosen to supply By methods, rather than On methods, because he on combinator can be used to get one in terms of the other. We explicitly added sortOn because it can use a Schwartzian transform to be more efficient than sortBy (comparing `on` f).

These don't have direct analogues there, however. So that usual argument against adding these sorts of methods doesn't hold up.

One thing of note is that what you are asking for here is usually called argmin and argmax. Perhaps consistency with the rest of mathematics should trump consistency with sortOn.

IIRC, We already have Arg in Data.Semigroup for use with the Min and Max semigroups for this purpose, so such naming would fit.

I'm not particularly concerned about the names that we decide. I just used those names because I thought they were intuitive for the current community. I'm happy with any other names that make sense.

Reply

Sign in to reply online Use email software

Tikhon Jelvis

29 May 29 May

2:43 a.m.

I've needed argmin and argmax a few times. In at least one of the cases I remember, I was implementing some algorithm that was specified with argmax in pseudocode, so those names make sense to me. On Fri, May 27, 2016 at 1:30 PM, Daniel Díaz Casanueva < dhelta.diaz@gmail.com> wrote:

On Fri, May 27, 2016 at 3:02 PM, Edward Kmett wrote:

...
Note: in general we have chosen to supply By methods, rather than On methods, because he on combinator can be used to get one in terms of the other. We explicitly added sortOn because it can use a Schwartzian transform to be more efficient than sortBy (comparing `on` f).

These don't have direct analogues there, however. So that usual argument against adding these sorts of methods doesn't hold up.

One thing of note is that what you are asking for here is usually called argmin and argmax. Perhaps consistency with the rest of mathematics should trump consistency with sortOn.

IIRC, We already have Arg in Data.Semigroup for use with the Min and Max semigroups for this purpose, so such naming would fit.

I'm not particularly concerned about the names that we decide. I just used those names because I thought they were intuitive for the current community. I'm happy with any other names that make sense.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Jon Fairbairn

30 May 30 May

4:11 a.m.

Daniel Díaz Casanueva writes:

I think these are useful in general, and that they would make a good addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions:

``` minOn :: Ord b => (a -> b) -> a -> a -> a minOn f x y = case comparing f x y of LT -> x _ -> y

Bad name; it’s too close to on min, which has the same type. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

Reply

Sign in to reply online Use email software

Ivan Lazar Miljenovic

4:16 a.m.

On 30 May 2016 at 18:11, Jon Fairbairn wrote:

Daniel Díaz Casanueva writes:

...
minOn :: Ord b => (a -> b) -> a -> a -> a minOn f x y = case comparing f x y of LT -> x _ -> y

Bad name; it’s too close to on min, which has the same type.

Not quite:

:t on min on min :: Ord c => (a -> c) -> a -> a -> c

(note the return type is different) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Reply

Sign in to reply online Use email software

Jon Fairbairn

4:29 a.m.

Ivan Lazar Miljenovic writes:

On 30 May 2016 at 18:11, Jon Fairbairn wrote:

...
Daniel Díaz Casanueva writes:

...
minOn :: Ord b => (a -> b) -> a -> a -> a minOn f x y = case comparing f x y of LT -> x _ -> y

Bad name; it’s too close to on min, which has the same type.

Not quite:

...
:t on min on min :: Ord c => (a -> c) -> a -> a -> c

(note the return type is different)

Yes, sorry. /nearly/ the same type. Still too much risk of confusion. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

Reply

Sign in to reply online Use email software

3277

Age (days ago)

3280

Last active (days ago)

Download

8 comments

6 participants

tags

participants (6)

Daniel Díaz Casanueva
Edward Kmett
Evan Laforge
Ivan Lazar Miljenovic
Jon Fairbairn
Tikhon Jelvis