Isnt this the reason we should add 0 at the beginning of the list? On 13/ott/2015, at 22:38, Matthias Felleisen <matth...@ccs.neu.edu> wrote:
> > Welcome to Racket v6.3.0.1. >> (define r .8) >> (for/last ([p '(a b c d)][f '(.2 .5 .7 1)] #:break (< r f)) p) > 'c > > Or WORSE: > >> (define r (random)) >> r > 0.011105628290672482 >> (for/last ([p '(a b c d)][f '(.2 .5 .7 1)] #:break (< r f)) p) > #f > > > > > On Oct 13, 2015, at 3:37 PM, Nguyen Linh Chi <nguyenlinhch...@gmail.com> > wrote: > >> the list 0 isnt a bug. I add it because #:break will break the fitness >> vector at r < f. >> >> For example, >> Population : a b c d >> Cumulative fitness .2 .5 .7 1 >> >> If the random r = .8, it means that the lottery points to the interval of >> automaton d. But #:break will breaks at .7, and the associated automaton is >> falsely identified as automaton c. >> >> (Hm, right?) >> >> On 13/ott/2015, at 20:21, Nguyen Linh Chi <nguyenlinhch...@gmail.com> wrote: >> >>> Hi Mathias, thank you so much for helping me a lot. >>> You can use the code as you want, i still have tons of them on my github. >>> (Just dont use it against me ok :D ) >>> >>> I'd try to see through your list of suggestions. >>> >>> About the automata payoff. >>> >>> There are 2 different things that are always mixed up: round and cycle. In >>> each cycle, automata are matched in pair and play a game for r rounds per >>> match. At the end of each cycle, there is a replacement period (respawning >>> the fittest). In what im doing, the payoff after r rounds is transformed >>> into the fitness, and the strongest automata (biggest payoff) survive. In >>> some sense they already carry on their relative payoff with them just >>> because they survive. >>> >>> Make the automaton carrying their absolute payoff history over cycles would >>> be intereting to see. I've never thought of that and the coding effort is >>> also a reason i havent tried. >>> >>> On 13/ott/2015, at 19:59, Matthias Felleisen <matth...@ccs.neu.edu> wrote: >>> >>>> >>>> p.s. One more question. Why do you 'reset' the payoff for automata after >>>> each round? Shouldn't they carry along their overall, historical payoff? >>>> >>>> >>>> >>>> >>>> On Oct 13, 2015, at 1:40 PM, Matthias Felleisen <matth...@ccs.neu.edu> >>>> wrote: >>>> >>>>> >>>>> 1. Your code is a good example for something that we could use as a >>>>> benchmark, and working on it has helped me find a couple of problems in >>>>> drracket and typed racket. Thanks for triggering my activity. I'll stop >>>>> soon. >>>>> >>>>> 2. I figured out that your code was general so you could accommodate more >>>>> situations than the ones you explored. My interest diverges from yours. >>>>> To me it is now just a cute benchmark. You will be able to use my >>>>> insights to speed up your performance: >>>>> >>>>> -- factor the program into separate modules/files, >>>>> -- make the modules independent of the representations, >>>>> -- change automata and population representations to use vectors instead >>>>> of lists, >>>>> -- avoid mutation, >>>>> -- eliminate all situations where you use (append l (list x)); instead >>>>> use cons and reverse the result at the end. >>>>> >>>>> That way you can run the program 6 times faster. >>>>> >>>>> 3. Otherwise I think your program needs real testing and I think there >>>>> are two bugs: >>>>> >>>>> a: I created a pull request for this one: >>>>> >>>>> >>>>> (define (accumulated-payoff-percentages payoff-list) >>>>> (define payoff-sum (apply + payoff-list)) >>>>> (define-values (accumulated _) >>>>> (for/fold ([accumulated (list 0)] ;; change to '(); otherwise you get a >>>>> list that's too long; your other for loop accidentally compensates for >>>>> this bug >>>>> [init 0]) >>>>> ([y (in-list payoff-list)]) >>>>> [define next-init (+ init (/ y payoff-sum))] >>>>> (values (cons next-init accumulated) next-init))) >>>>> (reverse accumulated)) >>>>> >>>>> b: I don't know how to fix this one properly: >>>>> >>>>> (define (randomise-over-fitness population fitness speed) >>>>> (for/list ([n (in-range speed)]) >>>>> [define r (random)] >>>>> (define candidate >>>>> (for/and ([p (in-vector population)] >>>>> [f (in-list fitness)] >>>>> #:break (< r f)) >>>>> p)) >>>>> candidate)) >>>>> >>>>> replace last line with something like this: >>>>> (or candidate (vector-ref population 0)))) >>>>> >>>>> Otherwise there is a non-0 chance otherwise that you get a boolean value >>>>> eventually. I am not sure which default value you want to throw in. >>>>> >>>>> 4. You're right: >>>>> >>>>> -- I re-created the match-pair function when I looked over my code. >>>>> -- using in-list and in-vector and in-range speeds up for loops. >>>>> -- types are irrelevant to your project. They helped me. >>>>> >>>>> I have pushed the last changes for now. Can we have your permission to >>>>> use this code for a benchmark in our research world? Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 13, 2015, at 12:00 PM, Linh Chi Nguyen <nguyenlinhch...@gmail.com> >>>>> wrote: >>>>> >>>>>> Matthias you work like a machine, too fast. >>>>>> >>>>>> Anyway, I have no idea what is type or not type. >>>>>> >>>>>> But I have some general remarks: >>>>>> >>>>>> 1. A general automaton can have many states, say, 10 states. >>>>>> >>>>>> so the action in each state can be either cooperate or defect (this is a >>>>>> deterministic automaton, for a probabilistic one, they can even >>>>>> randomise between cooperate or defect, but the case of deterministic and >>>>>> probabilistic should be separated far). >>>>>> >>>>>> it means that, even for a 2 state automaton, it can happen that both >>>>>> state use the same cooperate action. >>>>>> >>>>>> >>>>>> other small notices >>>>>> - the all defect automaton start with defecting and always defecting so >>>>>> its code is : defect defect defect... not cooperate defect defect... >>>>>> (same for the all cooperates one) >>>>>> >>>>>> - i'm considering to add a mutation phase at the end of each cycle (ie >>>>>> choose some random automaton and mutate their code) but im working very >>>>>> slow. >>>>>> >>>>>> - why dont you define a (match-pair ...) function separately? you insert >>>>>> it in the (match-population ...). doesnt it deserve to be outside? >>>>>> >>>>>> - why you use [i (in-range 10)] in all for loop? what's the difference >>>>>> with [i 10]. they both produce stream, right? >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, 13 October 2015 01:46:04 UTC+2, Matthias Felleisen wrote: >>>>>>> Take a crack at it. >>>>>>> >>>>>>> I am pretty sure I have introduced the proper level of representation >>>>>>> independence (I can hear Ben laugh all the way now — Typed Racket >>>>>>> doesn’t have types) and the typed documentation is pretty solid. (I’ll >>>>>>> do types later to validate.) >>>>>> >>>>>> -- >>>>>> 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. > -- 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.
