Alan Malloy <a...@malloys.org> writes:

Hi Alan,

>> Any hints?
>
> (1) The first version is doing way less work. It tries the first rule
> until it runs out of steam, then the second rule, then the third rule.
> If the third rule produces a structure that the first rule could have
> matched, it will never be tried, because the first rule is done. The
> second version, however, keeps reducing the structure using all three
> rules until there are no transformation available.

Yes, that's true.  However, in my test graph, it's basically a fixed
point reduction from 100000 elements to 16.  The first rule is the only
one that is able to produce a new match for the third rule.  It pulls
constants in trees of binary operations towards the leafs (for
commutative, associative ops) so that the third rule can evaluate them.
The second and third rule don't influence each other.

Hm, it's highly likely that you have to perform the first rule several
times to make the third rule applicable at all...

> (2) Your implementation of choose is pretty inefficient itself. rand-
> nth is slow, remove is slow...If you're using it in a performance-
> sensitive area, I would write it differently. Especially, you could
> probably gain a lot by making choose return a function, rather than
> immediately execute something, so that it can pre-compute the data
> that it will use more than once. Something like this (untested):

Ok, that's "only" 397 times slower which might also be a coincidence due
to the randomness. :-)

> (defn choose
>   [& funs]
>   (let [fnmap (vec funs)]

Why do you think this performs better than doing (vec funs) as init
expression in the loop (and then not returning a function but a value)?

>     (fn []
>       (loop [fns fnmap, tries-left (count fns)]
>         (when-not (zero? tries-left)
>           (let [idx (rand-int tries-left)
>                 f (get fns idx)
>                 val (f)]
>             (or val (recur (assoc fns idx
>                                   (get fns (dec tries-left)))
>                            (dec tries-left)))))))))

Bye,
Tassilo

-- 
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to