for/last: good point. Based on my previous experience with replacing imperative automata with functional ones, I don't think replacing the list-based population container with a vector per se will speed up things much. But the pairing up of neighbors might be a tad faster. Then again I would have to rewrite shuffle for imperative vectors.
I have pulled out the population for now so that you can play with this: https://github.com/mfelleisen/sample-fsm It's easy to run now from the command line. On Oct 12, 2015, at 11:17 AM, Gustavo Massaccesi <gust...@oma.org.ar> wrote: > Sorry for not testing before posting, but in this code: > > (define (randomise-over-fitness accumulated-payoff-percentage population > speed) > (for/list ([n (in-range speed)]) > [define r (random)] > (for/and ([p (in-list population)] > [a (in-list accumulated-payoff-percentage)] > #:break (< r a)) > p))) > > It looks like the population is stored in a list, and the changes in > the populations create more lists. I think that changing the > implementation to use vectors instead of list would make the code > faster. (But I haven't tested it.) > > Also, I think that for/and can be changed to for/last. I guess it will > almost no no change the speed, but it would make the intention > clearer. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
