On Jul 21, 11:23 pm, Alan Malloy <a...@malloys.org> wrote: > On Jul 21, 2:39 pm, Tassilo Horn <tass...@member.fsf.org> wrote: > > 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)? > > Because I only call choose once, in my implementation. Thus the vec > call only happens once; after that, iteratively is only calling the > function returned by choose.
But I agree, saving the three-element (vec) call is unlikely to make much difference; I was hoping there would be more work to take advantage of in the closure. -- 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
