Pfff... ttl strategy still broken...
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe
Hi,
On Mar 16, 8:13 am, Meikel Brandmeyer wrote:
> as threatened previously I wrote a summery blog post of this
> discussion: http://kotka.de/blog/2010/03/memoize_done_right.html.
> Please let me know in case I missed something crucial.
And updated with a protocol/type version for bleeding edge
Hi,
as threatened previously I wrote a summery blog post of this
discussion: http://kotka.de/blog/2010/03/memoize_done_right.html.
Please let me know in case I missed something crucial.
I'm also working on a protocol/type based implementation here:
http://paste.pocoo.org/show/190179. More to come
On Sun, Mar 14, 2010 at 2:06 PM, Eugen Dück wrote:
> I wonder whether we can make any statement about the likeliness of
> this happening in memoize6/7 vs. memoize7-variant or your memoize8,
> although it's unlikely to occur in all scenarios so far that I've
> wanted to use memoize in.
>
Anyway d
On Mar 14, 7:59 pm, Christophe Grand wrote:
> Well the fn passed to swap! can be retried so in case of "bad luck" you'll
> still create several delays.
You're absolutely right!
I wonder whether we can make any statement about the likeliness of
this happening in memoize6/7 vs. memoize7-variant or
Hi Meikel,
On Sun, Mar 14, 2010 at 9:42 AM, Meikel Brandmeyer wrote:
> > I agree: it can be concurrently computed several times (but a given
> thread
> > would only compute it at most once).
>
> On Sun, Mar 14, 2010 at 01:26:10AM +0100, Christophe Grand wrote:
> I must confess I was a little ins
Hi Eugen!
On Sun, Mar 14, 2010 at 6:51 AM, Eugen Dück wrote:
> your fifo-strategy (the one that uses "identity" as the hit method)
> does not work:
>
> user=> (def g (memoize7 identity (fifo-strategy 3)))
> #'user/g
> user=> (g 1)
> 1
> user=> (g 1)
> java.lang.IllegalArgumentException: Wrong nu
On Mar 14, 5:42 pm, Meikel Brandmeyer wrote:
> really shows, that concurrent programming is not trivial. Not even for
> „trivial“ things like a memoised function.
True. It's not too hard to be correct, but being correct and
performant at the same time is a different issue...
Thinking about your
Hi,
On Sun, Mar 14, 2010 at 01:26:10AM +0100, Christophe Grand wrote:
> I agree: it can be concurrently computed several times (but a given thread
> would only compute it at most once).
I must confess I was a little insisting on a point which has probably
only little impact in the real life. But
Hi Christophe,
your fifo-strategy (the one that uses "identity" as the hit method)
does not work:
user=> (def g (memoize7 identity (fifo-strategy 3)))
#'user/g
user=> (g 1)
1
user=> (g 1)
java.lang.IllegalArgumentException: Wrong number of args passed to:
core$identity (NO_SOURCE_FILE:0)
You hav
On Mar 14, 11:57 am, Eugen Dück wrote:
> This gap shrinks when using memoize7 thanks to the use of delays, but
> it is not completely closed and can still lead to multiple delays of
> the same computation. If we want to get rid off this gap and make it
Actually, I take that back. The delay might
On Mar 13, 4:51 pm, Christophe Grand wrote:
> My variations on memoize use a single atom: your bounded-memoize id roughly
> equivalent to my memoize2 + fifo-strategy,
> seehttp://gist.github.com/330644#LID19.
I finally found the time to fully read your gist, and I see you are
indeed
Hi Meikel,
On Sat, Mar 13, 2010 at 10:51 PM, Meikel Brandmeyer wrote:
> On Fri, Mar 12, 2010 at 08:27:15PM +0100, Christophe Grand wrote:
>
> > See my memoize5: the call isn't computed inside the swap!s
>
> That doesn't mean, that it is not computed several times!
>
I agree: it can be concurre
Hello Christophe,
On Fri, Mar 12, 2010 at 08:27:15PM +0100, Christophe Grand wrote:
> See my memoize5: the call isn't computed inside the swap!s
That doesn't mean, that it is not computed several times!
user=> (defn f
[x]
(println "Got" x "from" (Thread/currentThread))
Hi Eugen,
On Sat, Mar 13, 2010 at 3:28 AM, Eugen Dück wrote:
> I guess I must be missing something obvious, but can't we just put
> more than one thing into an atom in order to get atomic behavior?
>
My variations on memoize use a single atom: your bounded-memoize id roughly
eq
Laurent, Meikel, Christophe,
I guess I must be missing something obvious, but can't we just put
more than one thing into an atom in order to get atomic behavior?
Using, say, a vector. Using the simple bounded memoizer as an example,
this looks to me like it works:
(defn bounded-memoize
Hi Meikel,
Since Laurent dragged me into the discussion:
On Thu, Mar 11, 2010 at 8:42 AM, Meikel Brandmeyer wrote:
> Hello Laurent,
>
> On Mar 10, 11:45 am, Laurent PETIT wrote:
>
> > * usage of refs : I had a bad feeling, and cgrand confirmed this to
> > me by pointing an even more interesti
Hello Laurent,
On Mar 10, 11:45 am, Laurent PETIT wrote:
> * usage of refs : I had a bad feeling, and cgrand confirmed this to
> me by pointing an even more interesting counter-argument. Me: using
> refs is not mandatory since you do not need to synchronize this change
> with anything else.
I
2010/3/10 Steve Purcell :
> On 9 Mar 2010, at 23:22, Michał Marczyk wrote:
>
>> In the way of early feedback -- that's looks super neat! I've got this
>> instant feeling that this would be a great clojure.contrib.memoize.
>
>
> +1
>
> That would be wonderful.
Well, in the way of early feedback too
On 9 Mar 2010, at 23:22, Michał Marczyk wrote:
> In the way of early feedback -- that's looks super neat! I've got this
> instant feeling that this would be a great clojure.contrib.memoize.
+1
That would be wonderful.
--
You received this message because you are subscribed to the Google
Group
On 9 March 2010 23:17, Meikel Brandmeyer wrote:
> As threatened here a writeup. For this thread the Summary section is
> probably most interesting.
>
> http://kotka.de/blog/2010/03/The_Rule_of_Three.html#summary
>
> Sincerely
> Meikel
In the way of early feedback -- that's looks super neat! I've
As threatened here a writeup. For this thread the Summary section is
probably most interesting.
http://kotka.de/blog/2010/03/The_Rule_of_Three.html#summary
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
f insertion - I
> > guess I have to use refs and transactions now:
>
> > (defn bounded-memoize
> > [f bound]
> > (let [mem (ref {})
> > v (ref [])]
> > (fn [& args]
> > (if-let [e (find @mem args)]
> > (val e)
&
Hi again,
On Mar 9, 8:51 am, Meikel Brandmeyer wrote:
> (dissoc cache args))
And of course this is also wrong. Bleh. I will clean this up and do a
short blog post this evening...
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure
Woops. And of course there should be the check for bound in the update
functions of the lru and mu strategies...
(defn lru-cache-strategy
"Implements LRU cache strategy for memoize. At most bound number of
argument lists are kept in the cache. They are dropped in LRU
order."
[bound]
(let [
and transactions now:
>
> (defn bounded-memoize
> [f bound]
> (let [mem (ref {})
> v (ref [])]
> (fn [& args]
> (if-let [e (find @mem args)]
> (val e)
> (let [ret (apply f args)]
> (dosync
> (when (= (co
Good points! Testing array-map briefly led me to believe they can be
used as the clojure equivalent of Java\s LinkedHashMaps.
Here's a version that uses a vector to remember order of insertion - I
guess I have to use refs and transactions now:
(defn bounded-memoize
[f bound]
(let [mem
2010/3/9 André Ferreira :
> Conj adds to the end of a vector in constant time, but rest will not
> return another vector, but a sequence. Converting that sequence into
> another vector will take O(n). If you want queueing behaviour, you
> should use a clojure.lang.PersistentQueue:
> (-> clojure.lan
On 8 mar, 23:22, Michał Marczyk wrote:
> I'd suggest a vector instead; they're countable in constant time and
> you can use, say, conj and rest for add to end of queue / eject from
> front of queue.
Conj adds to the end of a vector in constant time, but rest will not
return another vector, but a
On 8 March 2010 05:31, Eugen Dück wrote:
> And here's a variant that evicts elements when the size of the cache
> exceeds some limit. In that case, the first item that was put in it
> will be dissoc'ed. I'm using an array-map to accomplish this:
I don't think this will work as you expect it to. T
sing an array-map to accomplish this:
(defn bounded-memoize
[f bound]
(let [mem (atom (array-map))]
(fn [& args]
(if-let [e (find @mem args)]
(val e)
(let [ret (apply f args)]
(swap! mem #(let [new-mem (assoc % args ret)]
(if
31 matches
Mail list logo
