On Dec 28, 12:26 pm, "Mark Engelberg" <mark.engelb...@gmail.com>
wrote:
> This iterative version doesn't behave properly if one of the sequences
> is empty. Expand should probably check for this degenerate case
> before passing the vector off to step.
I'll take care of that
Interesting. on my comp, the for loop runs about twice as slow as the
iterative version for a single set (#{\A \B} #{\C \D}..),
but slower when I'm subsequently (distinct (reduce clojure.set/union
the different sets within a host. So it loses some
time there. I might convert all the sets into strings before doing the
union.
iterative version:
"Elapsed time: 598.904 msecs"
451584
hard-coded for loop:
"Elapsed time: 1168.327 msecs"
451584
An alternative strategy that I'm looking at is to give the brics
automaton java engine another go. It has buildin functions to merge
regular expressions, and to generate these tuples. I only discarded it
earlier because I couldn't get it to be faster than the java regex
engine.. possibly because I used some inefficient way to check a whole
string. I'll email them.
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
