Capture the notion of invertible functions

Hi, These days I find the notion of "inverse function" might be useful, the basic idea is to keep a pair of function f and g which are the inverse functions of each other and then manipulate on this pair of functions. The detail is both on my blog post: http://javran.github.io/posts/2014-03-17-capture-the-notion-of-invertible-fu... and also code review: http://codereview.stackexchange.com/questions/44550/capture-the-notion-of-in... I think this is an interesting idea and want to share it with you. Advice and comments are welcomed and appreciated since I learn haskell through LYAH and some wiki pages and still not sure about what would be the most idiomatic way of doing it in haskell. Thanks, -- Javran (Fang) Cheng

Hi Javran,
1. Have you looked at iso lens? The lens library contextualizes
isomorphisms among other interesting maps. Worth looking into.
2. Your code looks nicely idiomatic. You must have worked hard observing
models of good haskell.
3. It's easy to declare at the type-level: a->b and b->a. It's just that
the types don't say anything about whether they are isos or not. Whereas
that's what we want.
Typically when I have such a pair of functions, I lean on quickcheck to
give me a rapid verify as I tweak away, e.g.:
prop_encdecOk :: String -> Bool
prop_encdecOk xs = xs == (decode . encode $ xs)
-- Kim-Ee
On Mon, Mar 17, 2014 at 2:44 PM, Javran Cheng
Hi,
These days I find the notion of "inverse function" might be useful, the basic idea is to keep a pair of function f and g which are the inverse functions of each other and then manipulate on this pair of functions.
The detail is both on my blog post:
http://javran.github.io/posts/2014-03-17-capture-the-notion-of-invertible-fu...
and also code review:
http://codereview.stackexchange.com/questions/44550/capture-the-notion-of-in...
I think this is an interesting idea and want to share it with you. Advice and comments are welcomed and appreciated since I learn haskell through LYAH and some wiki pages and still not sure about what would be the most idiomatic way of doing it in haskell.
Thanks,
-- Javran (Fang) Cheng
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Adding to Kim-Ee's point,
1) When you're talking about invertible functions, the idea you're probably
reaching for is an isomorphism -- that is, we want the function to have
certain nice properties on top of just being a map from a -> b with an
inverse map from b -> a. You also want the function to be a bijection,
which is captured in the notion of an isomorphism.
2) Iso from Lens composes with the normal function composition operator (.)
instead of rappend -- which is a little more convenient.
Arjun
On Mon, Mar 17, 2014 at 9:28 AM, Kim-Ee Yeoh
Hi Javran,
1. Have you looked at iso lens? The lens library contextualizes isomorphisms among other interesting maps. Worth looking into.
2. Your code looks nicely idiomatic. You must have worked hard observing models of good haskell.
3. It's easy to declare at the type-level: a->b and b->a. It's just that the types don't say anything about whether they are isos or not. Whereas that's what we want.
Typically when I have such a pair of functions, I lean on quickcheck to give me a rapid verify as I tweak away, e.g.:
prop_encdecOk :: String -> Bool prop_encdecOk xs = xs == (decode . encode $ xs)
-- Kim-Ee
On Mon, Mar 17, 2014 at 2:44 PM, Javran Cheng
wrote: Hi,
These days I find the notion of "inverse function" might be useful, the basic idea is to keep a pair of function f and g which are the inverse functions of each other and then manipulate on this pair of functions.
The detail is both on my blog post:
http://javran.github.io/posts/2014-03-17-capture-the-notion-of-invertible-fu...
and also code review:
http://codereview.stackexchange.com/questions/44550/capture-the-notion-of-in...
I think this is an interesting idea and want to share it with you. Advice and comments are welcomed and appreciated since I learn haskell through LYAH and some wiki pages and still not sure about what would be the most idiomatic way of doing it in haskell.
Thanks,
-- Javran (Fang) Cheng
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

When you're talking about invertible functions, the idea you're probably reaching for is an isomorphism -- that is, we want the function to have certain nice properties on top of just being a map from a -> b with an inverse map from b -> a.
The usual meaning of 'f is invertible' is that it is both left- and right-invertible, thus making it bijective: see first bullet in [1]. Here you're alluding to f being merely left-invertible, something I don't see mentioned in OP.
You also want the function to be a bijection, which is captured in the notion of an isomorphism.
I'm reminded of a reddit convo where the idea was tossed out that semigroups should always be promoted to monoids [2]. I argued no. I also cited a case where a supposedly nicer monoid causes more problems for a ghc hacker than the true semigroup [3]. Having structure is nice. And sometimes we just have to work with what's given to us. Category theory calls a /monomorphism/ something that's strictly weaker than left-invertible. An arrow that's (additionally) left-invertible corresponds to a /split mono/. Hence in order of _decreasing_ niceness: Iso, Split mono, Mono. As research uncovers more interesting phenomena, this sequence will continuing growing to the right. We can't always impose that niceness because that nukes whatever we're studying. So we gotta respect the situation. And given lemons, make lemonade. [1] http://en.wikipedia.org/wiki/Bijection,_injection_and_surjection#Bijection [2] http://www.reddit.com/r/haskell/comments/1ou06l/improving_applicative_donota... [3] http://www.reddit.com/r/haskell/comments/1ou06l/improving_applicative_donota...
participants (3)
-
Arjun Comar
-
Javran Cheng
-
Kim-Ee Yeoh