actually, if you look at the associated ticket, we have a version of clamp
that gives the right way to derive the onesided behaviors for even floating
point! (and has the correct / desirable behavior in the presence of NANs! )
On Wed, Aug 26, 2020 at 8:38 PM Jon Purdy
I’m also strongly for ‘clamp :: (Ord a) => (a, a) -> a -> a’.
Even if we don’t resolve it now, I do want to mention that, in discussing this with some acquaintances recently, we agreed that one-sided clamps likely warrant a home in ‘Data.Ord’ as well:
atLeast :: (Ord a) => a -> a -> a atLeast = max {-# INLINE atLeast #-}
atMost :: (Ord a) => a -> a -> a atMost = min {-# INLINE atMost #-}
clamp :: (Ord a) => (a, a) -> a -> a clamp (lower, upper) = atLeast lower . atMost upper
While their implementations are identical to ‘max’ and ‘min’, semantically they privilege their arguments differently, serving as documentation of intent in code like ‘nonnegative = fmap (atLeast 0)’. The hope is that this may help reduce bugs caused by the common error of mixing up ‘min’ and ‘max’, owing to the unfortunate false friendship between “at least/most” and “the least/most”.
On Sun, Aug 16, 2020 at 2:43 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Fri, 14 Aug 2020, Sandy Maguire wrote:
It seems to me that base is missing the very standard function `clamp :: Ord a => a -> a -> a -> a`:
```haskell clamp :: Ord a => a -> a -> a -> a clamp low high = min high .max low ```
https://hackage.haskell.org/package/utility-ht-0.0.15/docs/Data-Ord-HT.html#... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries