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.
