Thanks. I understood your intentions, and it didn't hurt for me to find my own solution.
(time (count (expand (first myset)))) "Elapsed time: 2426.327 msecs" 403200 Timing yours it is about as fast as the flexible for version, but not as fast as the tailored for version. Perhaps I should look at a way to approximate the score i am after, rather than caculate it exactly.. but at least these solutions let me check how good my approximation is. On Dec 28, 10:44 am, bOR_ <boris.sch...@gmail.com> wrote: > Ah. The prohibitively long bit comes mainly from printing out the > whole list in emacs. Counting it is only a few seconds, and not that > much slower than for the fixed-length version. In computer-time it is > still taking ages though. > > Why am I going through all of this?: I have 3 filters in the form of 3 > regular expressions. The combined filter looks something like this: > [ ACDFG][ ABEG][ BCDE][ ABCDG][ EF][ ABCDFG][ ABDEFG][ DG][ ABCDEFG]. > As the three filters are specified to have a specificity of 33%, 75% > and 5% of all strings that can be made of A..G of length 9, the > combined filter can at its best present 5% of all strings. What I am > interested in is to know how close to this optimum the combined filter > is. > > Wait. With a single filter this would be easy. 5% of all A..G, length > 9 would be 0.05 * 7^9, and the combined filter in this example has a > throughput of 5 * 4 * 4 * 5 * 2 ..etc. That would give the exact > answer. The problem I have is that I've about 3 or 4 of these combined > filters in a single host (hosts are diploid, so there's multiple > combinations of the three filters that can be made) and these filters > partially overlap. The only way I could think up to know exactly what > fraction of the optimum (2x 5%: remember the diploidi)) a set of > combined filters can present is by expanding these filters into a set > of all possible strings that they can present, and counting this set. > > The closeness to the optimum is a single number that reflects both the > co-evolvedness of the pathway, as the complementary-ness of the genes > in each layer, and is therefore a very nice measure to keep track of. > > 3010000 living: 955 infected: 946 > ave VL: 5.157769556025377 > pro alleles in population: 4 3.705294932579294 (692 456 442 > 320) > tap alleles in population: 2 1.0504241604755342 (1863 47) > mhc alleles in population: 7 4.623536807312288 (518 476 442 290 > 88 82 14) > "Elapsed time: 87142.965 msecs" > > (defn expand > "this version desperately needs tail recursion" > [sets] > (if (rrest sets) > (for [x (first sets) y (expand (rest sets))] (str x y)) > (for [x (first sets) y (second sets)] (str x y)))) > > (count (expand (first myset)))) > "Elapsed time: 2480.011 msecs" > 403200 > > (defn expand > "version tailored for windows of size 9" > [sets] > (let [input (vec sets)] > (for [a (input 0) b (input 1) c (input 2) d (input 3) e (input 4) > f (input 5) g (input 6) h (input 7) i (input 8)] (str a b c d e f g h > i)))) > > (count (expand (first myset)))) > "Elapsed time: 1850.148 msecs" > 403200 > > On Dec 28, 9:49 am, bOR_ <boris.sch...@gmail.com> wrote: > > > Annoying way to start a morning :P. Thanks though for the tip on > > htdp.org > > > This is what I cooked up, but apparently I can't make it use recur. It > > works for small sets, but it becomes prohibitively slow > > for collections of 6+ sets of letters. > > > (defn expand > > [sets] > > (if (rrest sets) > > (for [x (first sets) y (expand (rest sets))] (str x y)) > > (for [x (first sets) y (second sets)] (str x y)))) > > > On Dec 27, 11:35 pm, "Mark Engelberg" <mark.engelb...@gmail.com> > > wrote: > > > > On Sat, Dec 27, 2008 at 2:18 PM, bOR_ <boris.sch...@gmail.com> wrote: > > > > but > > > > didn't see an obvious/elegant way to do it in there, and the only way > > > > I'd write it now in clojure is going to be ugly. > > > > > Anyone has a suggestion? > > > > This kind of problem is straightforward if you understand recursion, > > > and the Clojure code is only a couple of elegant lines. But I'm > > > reluctant to "give it away" because it is worth your time to think > > > through this on your own. My suggestion is that you look at a book > > > like How to Design Programs (htdp.org), and work through some of the > > > exercises. Once you do, you'll find problems like this to be trivial. > > > Having a solid grounding in recursion will be very valuable when > > > working with Clojure. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
