Comments on: Elegant memoization with functional memo tries http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries Inspirations & experiments, mainly about denotative/functional programming in Haskell Mon, 21 Nov 2011 12:42:05 +0000 hourly 1 http://wordpress.org/?v=3.1 By: Conal Elliott » Blog Archive » Memoizing polymorphic functions via unmemoization http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-59067 Conal Elliott » Blog Archive » Memoizing polymorphic functions via unmemoization Sat, 02 Oct 2010 15:40:49 +0000 http://conal.net/blog/?p=54#comment-59067 <p>[...] can work out an answer by appealing to the same laws of exponents used in memoization, but now applied in reverse (to create function types instead of eliminate [...]</p> [...] can work out an answer by appealing to the same laws of exponents used in memoization, but now applied in reverse (to create function types instead of eliminate [...]

]]> By: Conal Elliott » Blog Archive » Memoizing higher-order functions http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-50257 Conal Elliott » Blog Archive » Memoizing higher-order functions Wed, 21 Jul 2010 15:41:24 +0000 http://conal.net/blog/?p=54#comment-50257 <p>[...] all at once from a denotational perspective, and incrementally from an operational perspective. See Elegant memoization with functional memo tries and Elegant memoization with higher-order [...]</p> [...] all at once from a denotational perspective, and incrementally from an operational perspective. See Elegant memoization with functional memo tries and Elegant memoization with higher-order [...]

]]> By: Conal Elliott » Blog Archive » Elegant memoization with higher-order types http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-50187 Conal Elliott » Blog Archive » Elegant memoization with higher-order types Wed, 21 Jul 2010 04:48:29 +0000 http://conal.net/blog/?p=54#comment-50187 <p>[...] using the essential idea of Ralf Hinze’s paper Generalizing Generalized Tries. The blog post Elegant memoization with functional memo tries describes a library, MemoTrie, based on both of these sources, and using associated data types. I [...]</p> [...] using the essential idea of Ralf Hinze’s paper Generalizing Generalized Tries. The blog post Elegant memoization with functional memo tries describes a library, MemoTrie, based on both of these sources, and using associated data types. I [...]

]]> By: Conal Elliott » Blog Archive » Nonstrict memoization http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-49242 Conal Elliott » Blog Archive » Nonstrict memoization Wed, 14 Jul 2010 02:46:28 +0000 http://conal.net/blog/?p=54#comment-49242 <p>[...] written a few posts about functional memoization. In one of them, Luke Palmer commented that the memoization methods are correct only for strict functions, which I [...]</p> [...] written a few posts about functional memoization. In one of them, Luke Palmer commented that the memoization methods are correct only for strict functions, which I [...]

]]> By: Conal Elliott » Blog Archive » Memoizing polymorphic functions - part two http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-32215 Conal Elliott » Blog Archive » Memoizing polymorphic functions - part two Fri, 20 Nov 2009 19:33:26 +0000 http://conal.net/blog/?p=54#comment-32215 <p>[...] Comments conal on Elegant memoization with functional memo triesShawn Willden on Elegant memoization with functional memo triesDave Crossland on Seeking advice on [...]</p> [...] Comments conal on Elegant memoization with functional memo triesShawn Willden on Elegant memoization with functional memo triesDave Crossland on Seeking advice on [...]

]]> By: conal http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-31832 conal Sat, 14 Nov 2009 19:22:02 +0000 http://conal.net/blog/?p=54#comment-31832 <p>@Shawn -- Fixed now. Thanks for the note.</p> @Shawn — Fixed now. Thanks for the note.

]]> By: Shawn Willden http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-31813 Shawn Willden Sat, 14 Nov 2009 07:13:13 +0000 http://conal.net/blog/?p=54#comment-31813 <p>Your source code links are broken. Could you please fix them so I can understand what it is you're talking about? Thanks.</p> Your source code links are broken. Could you please fix them so I can understand what it is you’re talking about? Thanks.

]]> By: Conal Elliott » Blog Archive » Memoizing polymorphic functions - part one http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-22207 Conal Elliott » Blog Archive » Memoizing polymorphic functions - part one Thu, 11 Jun 2009 00:36:40 +0000 http://conal.net/blog/?p=54#comment-22207 <p>[...] reuses rather than recomputes when applied to the same argument more than once. Variations include not-quite-equivalence due to added strictness, and replacing value equality with pointer [...]</p> [...] reuses rather than recomputes when applied to the same argument more than once. Variations include not-quite-equivalence due to added strictness, and replacing value equality with pointer [...]

]]> By: Conal Elliott » Blog Archive » Simpler, more efficient, functional linear maps http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-11163 Conal Elliott » Blog Archive » Simpler, more efficient, functional linear maps Sun, 09 Nov 2008 22:16:12 +0000 http://conal.net/blog/?p=54#comment-11163 <p>[...] However, there are several other ways to make linear maps, and it would be easy to forget to memoize each combining form. So, instead of the function representation above, I ensure that the function be memoized by representing it as a memo trie. [...]</p> [...] However, there are several other ways to make linear maps, and it would be easy to forget to memoize each combining form. So, instead of the function representation above, I ensure that the function be memoized by representing it as a memo trie. [...]

]]> By: Conal Elliott » Blog Archive » Vector space bases via type families http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-10304 Conal Elliott » Blog Archive » Vector space bases via type families Mon, 20 Oct 2008 01:23:36 +0000 http://conal.net/blog/?p=54#comment-10304 <p>[...] rules are also essentially the same as the ones used for memo tries, but phrased in terms of logarithms instead of (explicit) exponents. Tags: type families, vector [...]</p> [...] rules are also essentially the same as the ones used for memo tries, but phrased in terms of logarithms instead of (explicit) exponents. Tags: type families, vector [...]

]]> By: conal http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-10190 conal Thu, 16 Oct 2008 23:52:47 +0000 http://conal.net/blog/?p=54#comment-10190 <p>I said to <a href="http://luqui.org/blog" rel="nofollow">Luke</a></p> <blockquote> I'd love to read a blog post about your library, especially where you exploit the flexibility of explicit memoizers. </blockquote> <p>Oh! Now I see that you <a href="http://luqui.org/blog/archives/2008/10/14/data-memocombinators/" rel="nofollow">have written</a>. I'd still like to see some nice examples if you get around to it.</p> I said to Luke

I’d love to read a blog post about your library, especially where you exploit the flexibility of explicit memoizers.

Oh! Now I see that you have written. I’d still like to see some nice examples if you get around to it.

]]> By: Dave Menendez http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-10187 Dave Menendez Thu, 16 Oct 2008 21:27:21 +0000 http://conal.net/blog/?p=54#comment-10187 <blockquote> <p>Any thoughts on this dilemma?</p> </blockquote> <p>Well, there's not much point memoizing a constant function. Also, a strict instance for () is more consistent with the other instances.</p>

Any thoughts on this dilemma?

Well, there’s not much point memoizing a constant function. Also, a strict instance for () is more consistent with the other instances.

]]> By: conal http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-10183 conal Thu, 16 Oct 2008 17:21:31 +0000 http://conal.net/blog/?p=54#comment-10183 <blockquote> <p>[...] I don't think the typeclass approach to memoization is a good one. Here you are limited to one memo trie per type. But there are many ways to memoize a given type!</p> </blockquote> <p>Yep. A problem with typeclasses in general. Even more generally, a problem with hiding implementation mechanism. Prettier but less flexible. I gather you've found the flexibility particularly useful with memoization.</p> <blockquote> <p>data-memocombinators, which I just released on hackage two days ago [...]</p> </blockquote> <p>Sounds awfully cool. I'd love to read a blog post about your library, especially where you exploit the flexibility of explicit memoizers.</p>

[...] I don’t think the typeclass approach to memoization is a good one. Here you are limited to one memo trie per type. But there are many ways to memoize a given type!

Yep. A problem with typeclasses in general. Even more generally, a problem with hiding implementation mechanism. Prettier but less flexible. I gather you’ve found the flexibility particularly useful with memoization.

data-memocombinators, which I just released on hackage two days ago [...]

Sounds awfully cool. I’d love to read a blog post about your library, especially where you exploit the flexibility of explicit memoizers.

]]> By: conal http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-10182 conal Thu, 16 Oct 2008 17:11:11 +0000 http://conal.net/blog/?p=54#comment-10182 <blockquote> Memoization changes the strictness of functions. </blockquote> <p>Yow! It sure does. :(</p> <blockquote> this one is not essential, but rather a bug, I think. </blockquote> <p>Oh, I see the problem:</p> <p><div> <pre class="haskell">> <span style="color: #050; font-weight: bold;">let</span> f <span style="color: green;">(</span><span style="color: green;">)</span> = <span style="color: red;">42</span> > <span style="color: green;">(</span>\ <span style="color: green;">(</span><span style="color: green;">)</span> -> <span style="color: red;">42</span><span style="color: green;">)</span> <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:undefined" rel="nofollow"><span style="font-weight: bold;">undefined</span></a> *** Exception: <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html" rel="nofollow"><span style="colo: #050; font-weight: bold;">Prelude</span></a>.<a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:undefined" rel="nofollow"><span style="font-weight: bold;">undefined</span></a> > <span style="color: green;">(</span><a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:const" rel="nofollow"><span style="font-weight: bold;">const</span></a> <span style="color: red;">42</span><span style="color: green;">)</span> <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:undefined" rel="nofollow"><span style="font-weight: bold;">undefined</span></a> <span style="color: red;">42</span></pre> </div></p> <p>Hmm. I can fix the <code>f</code> case by changing the nonstrict <code>const a</code> to the strict <code>\ () -> a</code> in the definition of <code>untrie (UnitTrie a)</code>. But then I run into the dual problem:</p> <p><div> <pre class="haskell">> <span style="color: #050; font-weight: bold;">let</span> g = <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:const" rel="nofollow"><span style="font-weight: bold;">const</span></a> <span style="color: red;">42</span> :: <span style="color: green;">(</span><span style="color: green;">)</span> -> <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int" rel="nofollow"><span style="color: #833; font-weight: bold;">Int</span></a> > g <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:undefined" rel="nofollow"><span style="font-weight: bold;">undefined</span></a> <span style="color: red;">42</span> > memo g <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:undefined" rel="nofollow"><span style="font-weight: bold;">undefined</span></a> *** Exception: <a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html" rel="nofollow"><span style="colo: #050; font-weight: bold;">Prelude</span></a>.<a href="http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:undefined" rel="nofollow"><span style="font-weight: bold;">undefined</span></a></pre> </div></p> <p>Any thoughts on this dilemma?</p> Memoization changes the strictness of functions.

Yow! It sure does. :(

this one is not essential, but rather a bug, I think.

Oh, I see the problem:

> let f () = 42
> (\ () -> 42) undefined 
*** Exception: Prelude.undefined
> (const 42) undefined 
42

Hmm. I can fix the f case by changing the nonstrict const a to the strict \ () -> a in the definition of untrie (UnitTrie a). But then I run into the dual problem:

> let g = const 42 :: () -> Int
> g undefined
42
> memo g undefined
*** Exception: Prelude.undefined

Any thoughts on this dilemma?

]]> By: Luke Palmer http://conal.net/blog/posts/elegant-memoization-with-functional-memo-tries/comment-page-1#comment-10166 Luke Palmer Thu, 16 Oct 2008 08:42:43 +0000 http://conal.net/blog/?p=54#comment-10166 <p>Oh, your semantics are not quite right. Memoization changes the strictness of functions.</p> <pre> take 5 (repeat True) = [True,True,True,True,True] memo (take 5) (repeat True) = ⊥ -- this one is not essential, but rather a bug, I think. let f () = 42 f ⊥ = ⊥ memo f ⊥ = 42 </pre> <p>I am not quite sure in what essential way the strictness is changed. For example, it is theoretically possible to memoize a function of infinite streams, given that the return type is compact, so it's not just that it makes it fully strict in its argument's domain. I haven't gotten around to implementing this awesome possibility just yet :-)</p> Oh, your semantics are not quite right. Memoization changes the strictness of functions.

    take 5 (repeat True)        = [True,True,True,True,True]
    memo (take 5) (repeat True) = ⊥
    
    -- this one is not essential, but rather a bug, I think.
    let f () = 42
    f ⊥      = ⊥
    memo f ⊥ = 42

I am not quite sure in what essential way the strictness is changed. For example, it is theoretically possible to memoize a function of infinite streams, given that the return type is compact, so it’s not just that it makes it fully strict in its argument’s domain. I haven’t gotten around to implementing this awesome possibility just yet :-)

]]>