On Dec 28, 2013, at 3:11 PM, Cedric Greevey wrote: > Adding to the above, in the specific context of genetic programming, I'd > suggest dividing the population into N subsets, one per core, and trialling > them in parallel to generate fitness scores; then parallel-mergesort to get a > ranked order; then (apply map vector (partition (/ num-to-keep num-cores) > (take num-to-keep sorted-population))) to cull all but the best num-to-keep > and distribute them across N new subsets with each subset a representative > sample of the range of fitness scores (so any correlation between trial speed > and fitness won't make some populations slow and stop), then apply any > recombination/crossovers to generate, say, M new genomes in each subset > (parallel, uses the static data from the previous round and per-thread PRNGs > to decide which pairs of survivors to use to make offspring added to that > thread's subpopulation), then apply mutation (parallel, each thread mutates > its own subpopulation), then next trial... No thread-order-of-action > dependencies this way. Snapshot once a round by saving the subpopulations and > per-thread PRNG internal states right before each fitness trial phase. > Snapshot should evolve deterministically if restored with the same values for > num-to-keep and num-cores and whatever other parameters. Last snapshot before > crash should crash the same way every time.
Some of what you're suggesting would have implications for evolutionary dynamics. Maybe good, maybe bad, some related to things that I and others have studied (e.g. various schemes for working with subpopulations), and some maybe incompatible with other experimental things that I may be working with. I'm a researcher in this area, so I do care about and have tried related things for various reasons, but I don't want my search/evolution algorithm design to be driven by inadequacies of my programming environment (e.g. difficulties in finding sources of crashes). -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
