Data.Map.mapKeysMonotonic is a misleading name

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Data.Map.mapKeysMonotonic is a misleading name

Elliot Cameron-2

Hello!

In some recent analysis I ran into a subtlety that caught me by surprise: Data.Map.mapKeysMonotonic has a misleading name.

A monotonic function is not a strictly increasing function, but merely non-decreasing. However, mapKeysMonotonic requires that it's mapping function be injective, which means it really only supports increasing functions.

valid (mapKeysMonotonic (\x -> if x `elem` [1,2] then 2 else x) (fromList [(1, "a"), (2, "b"), (3, "c")])) == False

The docs hint at this with "This means that @f@ maps distinct original keys to distinct resulting keys."

However, I'd propose that we deprecate this name and rename to something like mapKeysIncreasingor mapKeysAsc (to follow the pattern of other *Asc functions). We should also clarify the docs.



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

David Feuer
We can't use "increasing" because mathematically that usually means non-strictly increasing. Using "ascending" gets us in trouble with the other functions in the module that use the word in a non-strict sense.

On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron <[hidden email]> wrote:

Hello!

In some recent analysis I ran into a subtlety that caught me by surprise: Data.Map.mapKeysMonotonic has a misleading name.

A monotonic function is not a strictly increasing function, but merely non-decreasing. However, mapKeysMonotonic requires that it's mapping function be injective, which means it really only supports increasing functions.

valid (mapKeysMonotonic (\x -> if x `elem` [1,2] then 2 else x) (fromList [(1, "a"), (2, "b"), (3, "c")])) == False

The docs hint at this with "This means that @f@ maps distinct original keys to distinct resulting keys."

However, I'd propose that we deprecate this name and rename to something like mapKeysIncreasingor mapKeysAsc (to follow the pattern of other *Asc functions). We should also clarify the docs.


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Elliot Cameron-2
Yeah the clearest names seem to be really long ones: mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing, mapKeysReferToDocs, etc.

On Wed, Apr 3, 2019 at 11:11 AM David Feuer <[hidden email]> wrote:
We can't use "increasing" because mathematically that usually means non-strictly increasing. Using "ascending" gets us in trouble with the other functions in the module that use the word in a non-strict sense.

On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron <[hidden email]> wrote:

Hello!

In some recent analysis I ran into a subtlety that caught me by surprise: Data.Map.mapKeysMonotonic has a misleading name.

A monotonic function is not a strictly increasing function, but merely non-decreasing. However, mapKeysMonotonic requires that it's mapping function be injective, which means it really only supports increasing functions.

valid (mapKeysMonotonic (\x -> if x `elem` [1,2] then 2 else x) (fromList [(1, "a"), (2, "b"), (3, "c")])) == False

The docs hint at this with "This means that @f@ maps distinct original keys to distinct resulting keys."

However, I'd propose that we deprecate this name and rename to something like mapKeysIncreasingor mapKeysAsc (to follow the pattern of other *Asc functions). We should also clarify the docs.


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Andreas Abel
I am not sure this subtlety is worth the breakage and annoyance to users
coming with the name change.
If you think about it, renaming the keys while preserving the tree
structure cannot work if two old keys map to the same new key.

On 2019-04-03 17:13, Elliot Cameron wrote:

> Yeah the clearest names seem to be really long ones:
> mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
> mapKeysReferToDocs, etc.
>
> On Wed, Apr 3, 2019 at 11:11 AM David Feuer <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     We can't use "increasing" because mathematically that usually means
>     non-strictly increasing. Using "ascending" gets us in trouble with
>     the other functions in the module that use the word in a non-strict
>     sense.
>
>     On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hello!
>
>         In some recent analysis I ran into a subtlety that caught me by
>         surprise: Data.Map.mapKeysMonotonic has a misleading name.
>
>         A monotonic function is not a strictly /increasing/ function,
>         but merely non-decreasing. However, |mapKeysMonotonic| requires
>         that it's mapping function be injective, which means it really
>         only supports /increasing/ functions.
>
>         valid (mapKeysMonotonic (\x->  if  x`elem`  [1,2]then  2  else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False
>
>         The docs hint at this with "This means that @f
>         <https://github.com/f>@ maps distinct original keys to distinct
>         resulting keys."
>
>         However, I'd propose that we deprecate this name and rename to
>         something like |mapKeysIncreasing|or |mapKeysAsc| (to follow the
>         pattern of other *Asc functions). We should also clarify the docs.
>
>
>          From https://github.com/haskell/containers/issues/617
>         _______________________________________________
>         Libraries mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Elliot Cameron-2
Well I'm proposing deprecation not removal. The deprecation could even live forever for all I care. It would point to the new name as well. Not to mention I doubt this function is used very often.

On Thu, Apr 4, 2019, 2:58 AM Andreas Abel <[hidden email]> wrote:
I am not sure this subtlety is worth the breakage and annoyance to users
coming with the name change.
If you think about it, renaming the keys while preserving the tree
structure cannot work if two old keys map to the same new key.

On 2019-04-03 17:13, Elliot Cameron wrote:
> Yeah the clearest names seem to be really long ones:
> mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
> mapKeysReferToDocs, etc.
>
> On Wed, Apr 3, 2019 at 11:11 AM David Feuer <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     We can't use "increasing" because mathematically that usually means
>     non-strictly increasing. Using "ascending" gets us in trouble with
>     the other functions in the module that use the word in a non-strict
>     sense.
>
>     On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hello!
>
>         In some recent analysis I ran into a subtlety that caught me by
>         surprise: Data.Map.mapKeysMonotonic has a misleading name.
>
>         A monotonic function is not a strictly /increasing/ function,
>         but merely non-decreasing. However, |mapKeysMonotonic| requires
>         that it's mapping function be injective, which means it really
>         only supports /increasing/ functions.
>
>         valid (mapKeysMonotonic (\x->  if  x`elem`  [1,2]then  2  else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False
>
>         The docs hint at this with "This means that @f
>         <https://github.com/f>@ maps distinct original keys to distinct
>         resulting keys."
>
>         However, I'd propose that we deprecate this name and rename to
>         something like |mapKeysIncreasing|or |mapKeysAsc| (to follow the
>         pattern of other *Asc functions). We should also clarify the docs.
>
>
>          From https://github.com/haskell/containers/issues/617
>         _______________________________________________
>         Libraries mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Andreas Abel
 > I doubt this function is used very often.

You could be mistaken.  Me, too.  Without statistical data, I have 0
confidence in such estimates of brain 1.
https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow

On 2019-04-04 14:46, Elliot Cameron wrote:

> Well I'm proposing deprecation not removal. The deprecation could even
> live forever for all I care. It would point to the new name as well. Not
> to mention I doubt this function is used very often.
>
> On Thu, Apr 4, 2019, 2:58 AM Andreas Abel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I am not sure this subtlety is worth the breakage and annoyance to
>     users
>     coming with the name change.
>     If you think about it, renaming the keys while preserving the tree
>     structure cannot work if two old keys map to the same new key.
>
>     On 2019-04-03 17:13, Elliot Cameron wrote:
>      > Yeah the clearest names seem to be really long ones:
>      > mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
>      > mapKeysReferToDocs, etc.
>      >
>      > On Wed, Apr 3, 2019 at 11:11 AM David Feuer
>     <[hidden email] <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     We can't use "increasing" because mathematically that usually
>     means
>      >     non-strictly increasing. Using "ascending" gets us in trouble
>     with
>      >     the other functions in the module that use the word in a
>     non-strict
>      >     sense.
>      >
>      >     On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron
>     <[hidden email] <mailto:[hidden email]>
>      >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >         Hello!
>      >
>      >         In some recent analysis I ran into a subtlety that caught
>     me by
>      >         surprise: Data.Map.mapKeysMonotonic has a misleading name.
>      >
>      >         A monotonic function is not a strictly /increasing/ function,
>      >         but merely non-decreasing. However,
>     |mapKeysMonotonic| requires
>      >         that it's mapping function be injective, which means it
>     really
>      >         only supports /increasing/ functions.
>      >
>      >         valid (mapKeysMonotonic (\x->  if  x`elem`  [1,2]then  2
>     else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False
>      >
>      >         The docs hint at this with "This means that @f
>      >         <https://github.com/f>@ maps distinct original keys to
>     distinct
>      >         resulting keys."
>      >
>      >         However, I'd propose that we deprecate this name and
>     rename to
>      >         something like |mapKeysIncreasing|or |mapKeysAsc| (to
>     follow the
>      >         pattern of other *Asc functions). We should also clarify
>     the docs.
>      >
>      >
>      >          From https://github.com/haskell/containers/issues/617
>      >         _______________________________________________
>      >         Libraries mailing list
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      >
>      >
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      >
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Artyom Kazak-2
It's not used _very_ often, but it does appear a few times on Hackage. For instance, it's used several times in Agda source: <a href="https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&amp;filter=Data.Map(+|$)&amp;insensitive=off&amp;space=off&amp;precise=off&amp;sources=on&amp;page=1" title="https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&amp;filter=Data.Map(+|$)&amp;insensitive=off&amp;space=off&amp;precise=off&amp;sources=on&amp;page=1">https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+|$)&insensitive=off&space=off&precise=off&sources=on&page=1

On Apr 4 2019, at 3:19 pm, Andreas Abel <[hidden email]> wrote:
> I doubt this function is used very often.

You could be mistaken. Me, too. Without statistical data, I have 0
confidence in such estimates of brain 1.
https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow

On 2019-04-04 14:46, Elliot Cameron wrote:
Well I'm proposing deprecation not removal. The deprecation could even
live forever for all I care. It would point to the new name as well. Not
to mention I doubt this function is used very often.

On Thu, Apr 4, 2019, 2:58 AM Andreas Abel <[hidden email]
<mailto:[hidden email]>> wrote:

I am not sure this subtlety is worth the breakage and annoyance to
users
coming with the name change.
If you think about it, renaming the keys while preserving the tree
structure cannot work if two old keys map to the same new key.

On 2019-04-03 17:13, Elliot Cameron wrote:
Yeah the clearest names seem to be really long ones:
mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
mapKeysReferToDocs, etc.

On Wed, Apr 3, 2019 at 11:11 AM David Feuer
<mailto:[hidden email] <mailto:[hidden email]>>> wrote:

     We can't use "increasing" because mathematically that usually
means
     non-strictly increasing. Using "ascending" gets us in trouble
with
     the other functions in the module that use the word in a
non-strict
     sense.

     On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron
     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

         Hello!

         In some recent analysis I ran into a subtlety that caught
me by
         surprise: Data.Map.mapKeysMonotonic has a misleading name.

         A monotonic function is not a strictly /increasing/ function,
         but merely non-decreasing. However,
|mapKeysMonotonic| requires
         that it's mapping function be injective, which means it
really
         only supports /increasing/ functions.

         valid (mapKeysMonotonic (\x->  if  x`elem`  [1,2]then  2
else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False

         The docs hint at this with "This means that @f
         <https://github.com/f>@ maps distinct original keys to
distinct
         resulting keys."

         However, I'd propose that we deprecate this name and
rename to
         something like |mapKeysIncreasing|or |mapKeysAsc| (to
follow the
         pattern of other *Asc functions). We should also clarify
the docs.


          From https://github.com/haskell/containers/issues/617
         _______________________________________________
         Libraries mailing list
<mailto:[hidden email] <mailto:[hidden email]>>
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Elliot Cameron-2
Thanks Artyom. That's useful. In fact in highlights the original motivation for my request. Data.Map his numerous wrappers and clones (I happened to be working on monoidal-containers) and this name keeps getting spread throughout them. In the case of a monoidal-containers, mapKeysMonotonic only makes sense with a Semigroup constraint on the values (because a monotonic function can still cause keys to get merged). But now the name is even more confusing: what happens to duplicate keys: are they merged with Data.Map's infamous left-bias? Are they <>ed together? But that can't be since there is no Semigroup constraint... Your search shows that this same name is also used in IntervalMap and Agda for the very reason that it matches the name in Data.Map!

So my true hope is that a) people won't be confused by this function and b) people will stop using this name in wrappers/clones if it's not actually the appropriate name.

On Thu, Apr 4, 2019 at 9:51 AM Artyom Kazak <[hidden email]> wrote:
It's not used _very_ often, but it does appear a few times on Hackage. For instance, it's used several times in Agda source: https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+|$)&insensitive=off&space=off&precise=off&sources=on&page=1

On Apr 4 2019, at 3:19 pm, Andreas Abel <[hidden email]> wrote:
> I doubt this function is used very often.

You could be mistaken. Me, too. Without statistical data, I have 0
confidence in such estimates of brain 1.

On 2019-04-04 14:46, Elliot Cameron wrote:
Well I'm proposing deprecation not removal. The deprecation could even
live forever for all I care. It would point to the new name as well. Not
to mention I doubt this function is used very often.

On Thu, Apr 4, 2019, 2:58 AM Andreas Abel <[hidden email]
<mailto:[hidden email]>> wrote:

I am not sure this subtlety is worth the breakage and annoyance to
users
coming with the name change.
If you think about it, renaming the keys while preserving the tree
structure cannot work if two old keys map to the same new key.

On 2019-04-03 17:13, Elliot Cameron wrote:
Yeah the clearest names seem to be really long ones:
mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
mapKeysReferToDocs, etc.

On Wed, Apr 3, 2019 at 11:11 AM David Feuer
<mailto:[hidden email] <mailto:[hidden email]>>> wrote:

     We can't use "increasing" because mathematically that usually
means
     non-strictly increasing. Using "ascending" gets us in trouble
with
     the other functions in the module that use the word in a
non-strict
     sense.

     On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron
     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

         Hello!

         In some recent analysis I ran into a subtlety that caught
me by
         surprise: Data.Map.mapKeysMonotonic has a misleading name.

         A monotonic function is not a strictly /increasing/ function,
         but merely non-decreasing. However,
|mapKeysMonotonic| requires
         that it's mapping function be injective, which means it
really
         only supports /increasing/ functions.

         valid (mapKeysMonotonic (\x->  if  x`elem`  [1,2]then  2
else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False

         The docs hint at this with "This means that @f
         <https://github.com/f>@ maps distinct original keys to
distinct
         resulting keys."

         However, I'd propose that we deprecate this name and
rename to
         something like |mapKeysIncreasing|or |mapKeysAsc| (to
follow the
         pattern of other *Asc functions). We should also clarify
the docs.


         _______________________________________________
         Libraries mailing list
<mailto:[hidden email] <mailto:[hidden email]>>


_______________________________________________
Libraries mailing list
_______________________________________________
Libraries mailing list
_______________________________________________
Libraries mailing list

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Andreas Abel
Elliot,

Maybe as a German I do not stumble over that use of "monotonic" in the
same way as you might.  In German, we have

   <= monoton steigend
   >= monoton fallend
   <  streng monoton steigend
   >  streng monoton fallend

Thus, "monoton" by itself is not a precise notion, but refers to the
family of these concepts (although it is a bit sloppily often used for
"monoton steigend").  The German precise name of mapKeysMonotonic would be

   transformiereSchlüsselStrengMonotonSteigend

and you can see that using fully precise names get you nowhere in my
context. :D

However, my question still stands what else than "strictly increasing"
could be meant in "mapKeysMonotonic"?  If it is not an injective
function you pass to it, then what can be the advantage over the general
"mapKeysWith"?  And how likely is the case that a
"mapKeysNonStrictlyIncreasing" would be preferable over "mapKeysWith",
justifying the extra implementation of a "mapKeysNonStrictlyIncreasing"?

Cheers,
Andreas

On 2019-04-04 16:58, Elliot Cameron wrote:

> Thanks Artyom. That's useful. In fact in highlights the original
> motivation for my request. Data.Map his numerous wrappers and clones (I
> happened to be working on monoidal-containers) and this name keeps
> getting spread throughout them. In the case of a monoidal-containers,
> mapKeysMonotonic only makes sense with a Semigroup constraint on the
> values (because a monotonic function can still cause keys to get
> merged). But now the name is even more confusing: what happens to
> duplicate keys: are they merged with Data.Map's infamous left-bias? Are
> they <>ed together? But that can't be since there is no Semigroup
> constraint... Your search shows that this same name is also used in
> IntervalMap and Agda for the very reason that it matches the name in
> Data.Map!
>
> So my true hope is that a) people won't be confused by this function and
> b) people will stop using this name in wrappers/clones if it's not
> /actually/ the appropriate name.
>
> On Thu, Apr 4, 2019 at 9:51 AM Artyom Kazak <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     It's not used _very_ often, but it does appear a few times on
>     Hackage. For instance, it's used several times in Agda source:
>     https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+|$)&insensitive=off&space=off&precise=off&sources=on&page=1
>     <https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+%7C$)&insensitive=off&space=off&precise=off&sources=on&page=1>
>
>     On Apr 4 2019, at 3:19 pm, Andreas Abel <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>          > I doubt this function is used very often.
>
>         You could be mistaken. Me, too. Without statistical data, I have 0
>         confidence in such estimates of brain 1.
>         https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow
>
>         On 2019-04-04 14:46, Elliot Cameron wrote:
>
>             Well I'm proposing deprecation not removal. The deprecation
>             could even
>             live forever for all I care. It would point to the new name
>             as well. Not
>             to mention I doubt this function is used very often.
>
>             On Thu, Apr 4, 2019, 2:58 AM Andreas Abel
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> wrote:
>
>             I am not sure this subtlety is worth the breakage and
>             annoyance to
>             users
>             coming with the name change.
>             If you think about it, renaming the keys while preserving
>             the tree
>             structure cannot work if two old keys map to the same new key.
>
>             On 2019-04-03 17:13, Elliot Cameron wrote:
>
>                 Yeah the clearest names seem to be really long ones:
>                 mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
>                 mapKeysReferToDocs, etc.
>
>                 On Wed, Apr 3, 2019 at 11:11 AM David Feuer
>
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>>> wrote:
>
>                       We can't use "increasing" because mathematically
>                 that usually
>
>             means
>
>                       non-strictly increasing. Using "ascending" gets us
>                 in trouble
>
>             with
>
>                       the other functions in the module that use the
>                 word in a
>
>             non-strict
>
>                       sense.
>
>                       On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron
>
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>
>                       <mailto:[hidden email]
>                 <mailto:[hidden email]> <mailto:[hidden email]
>                 <mailto:[hidden email]>>>> wrote:
>
>                           Hello!
>
>                           In some recent analysis I ran into a subtlety
>                 that caught
>
>             me by
>
>                           surprise: Data.Map.mapKeysMonotonic has a
>                 misleading name.
>
>                           A monotonic function is not a strictly
>                 /increasing/ function,
>                           but merely non-decreasing. However,
>
>             |mapKeysMonotonic| requires
>
>                           that it's mapping function be injective, which
>                 means it
>
>             really
>
>                           only supports /increasing/ functions.
>
>                           valid (mapKeysMonotonic (\x->  if  x`elem`
>                 [1,2]then  2
>
>             else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False
>
>
>                           The docs hint at this with "This means that @f
>                           <https://github.com/f>@ maps distinct original
>                 keys to
>
>             distinct
>
>                           resulting keys."
>
>                           However, I'd propose that we deprecate this
>                 name and
>
>             rename to
>
>                           something like |mapKeysIncreasing|or
>                 |mapKeysAsc| (to
>
>             follow the
>
>                           pattern of other *Asc functions). We should
>                 also clarify
>
>             the docs.
>
>
>
>                            From
>                 https://github.com/haskell/containers/issues/617
>                           _______________________________________________
>                           Libraries mailing list
>                 [hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>
>
>             <mailto:[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>>
>
>                 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>                 _______________________________________________
>                 Libraries mailing list
>                 [hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>
>                 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>             _______________________________________________
>             Libraries mailing list
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>         _______________________________________________
>         Libraries mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Map.mapKeysMonotonic is a misleading name

Elliot Cameron-2
I guess I just want names to say what they mean and not require me to deduce what they must mean based on other, possibly invisible, constraints. If we can come up with a good name for this then I'd even be happier if we simply added an alias with a less-confusing name and didn't even formally deprecate the other one. Can some suggest such a name? I've tossed a few out: mapKeysInjectiveIncreasing, mapKeysStrictlyIncreasing, mapKeysMonotonicDistinct

On Thu, Apr 4, 2019 at 3:57 PM Andreas Abel <[hidden email]> wrote:
Elliot,

Maybe as a German I do not stumble over that use of "monotonic" in the
same way as you might.  In German, we have

   <= monoton steigend
   >= monoton fallend
   <  streng monoton steigend
   >  streng monoton fallend

Thus, "monoton" by itself is not a precise notion, but refers to the
family of these concepts (although it is a bit sloppily often used for
"monoton steigend").  The German precise name of mapKeysMonotonic would be

   transformiereSchlüsselStrengMonotonSteigend

and you can see that using fully precise names get you nowhere in my
context. :D

However, my question still stands what else than "strictly increasing"
could be meant in "mapKeysMonotonic"?  If it is not an injective
function you pass to it, then what can be the advantage over the general
"mapKeysWith"?  And how likely is the case that a
"mapKeysNonStrictlyIncreasing" would be preferable over "mapKeysWith",
justifying the extra implementation of a "mapKeysNonStrictlyIncreasing"?

Cheers,
Andreas

On 2019-04-04 16:58, Elliot Cameron wrote:
> Thanks Artyom. That's useful. In fact in highlights the original
> motivation for my request. Data.Map his numerous wrappers and clones (I
> happened to be working on monoidal-containers) and this name keeps
> getting spread throughout them. In the case of a monoidal-containers,
> mapKeysMonotonic only makes sense with a Semigroup constraint on the
> values (because a monotonic function can still cause keys to get
> merged). But now the name is even more confusing: what happens to
> duplicate keys: are they merged with Data.Map's infamous left-bias? Are
> they <>ed together? But that can't be since there is no Semigroup
> constraint... Your search shows that this same name is also used in
> IntervalMap and Agda for the very reason that it matches the name in
> Data.Map!
>
> So my true hope is that a) people won't be confused by this function and
> b) people will stop using this name in wrappers/clones if it's not
> /actually/ the appropriate name.
>
> On Thu, Apr 4, 2019 at 9:51 AM Artyom Kazak <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     It's not used _very_ often, but it does appear a few times on
>     Hackage. For instance, it's used several times in Agda source:
>     https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+|$)&insensitive=off&space=off&precise=off&sources=on&page=1
>     <https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+%7C$)&insensitive=off&space=off&precise=off&sources=on&page=1>
>
>     On Apr 4 2019, at 3:19 pm, Andreas Abel <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>          > I doubt this function is used very often.
>
>         You could be mistaken. Me, too. Without statistical data, I have 0
>         confidence in such estimates of brain 1.
>         https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow
>
>         On 2019-04-04 14:46, Elliot Cameron wrote:
>
>             Well I'm proposing deprecation not removal. The deprecation
>             could even
>             live forever for all I care. It would point to the new name
>             as well. Not
>             to mention I doubt this function is used very often.
>
>             On Thu, Apr 4, 2019, 2:58 AM Andreas Abel
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> wrote:
>
>             I am not sure this subtlety is worth the breakage and
>             annoyance to
>             users
>             coming with the name change.
>             If you think about it, renaming the keys while preserving
>             the tree
>             structure cannot work if two old keys map to the same new key.
>
>             On 2019-04-03 17:13, Elliot Cameron wrote:
>
>                 Yeah the clearest names seem to be really long ones:
>                 mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
>                 mapKeysReferToDocs, etc.
>
>                 On Wed, Apr 3, 2019 at 11:11 AM David Feuer
>
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>>> wrote:
>
>                       We can't use "increasing" because mathematically
>                 that usually
>
>             means
>
>                       non-strictly increasing. Using "ascending" gets us
>                 in trouble
>
>             with
>
>                       the other functions in the module that use the
>                 word in a
>
>             non-strict
>
>                       sense.
>
>                       On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron
>
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>
>                       <mailto:[hidden email]
>                 <mailto:[hidden email]> <mailto:[hidden email]
>                 <mailto:[hidden email]>>>> wrote:
>
>                           Hello!
>
>                           In some recent analysis I ran into a subtlety
>                 that caught
>
>             me by
>
>                           surprise: Data.Map.mapKeysMonotonic has a
>                 misleading name.
>
>                           A monotonic function is not a strictly
>                 /increasing/ function,
>                           but merely non-decreasing. However,
>
>             |mapKeysMonotonic| requires
>
>                           that it's mapping function be injective, which
>                 means it
>
>             really
>
>                           only supports /increasing/ functions.
>
>                           valid (mapKeysMonotonic (\x->  if  x`elem`
>                 [1,2]then  2
>
>             else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False
>
>
>                           The docs hint at this with "This means that @f
>                           <https://github.com/f>@ maps distinct original
>                 keys to
>
>             distinct
>
>                           resulting keys."
>
>                           However, I'd propose that we deprecate this
>                 name and
>
>             rename to
>
>                           something like |mapKeysIncreasing|or
>                 |mapKeysAsc| (to
>
>             follow the
>
>                           pattern of other *Asc functions). We should
>                 also clarify
>
>             the docs.
>
>
>
>                            From
>                 https://github.com/haskell/containers/issues/617
>                           _______________________________________________
>                           Libraries mailing list
>                 [hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>
>
>             <mailto:[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>>
>
>                 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>                 _______________________________________________
>                 Libraries mailing list
>                 [hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>
>                 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>             _______________________________________________
>             Libraries mailing list
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>         _______________________________________________
>         Libraries mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries