Re: [racket-users] help on coding finite state automata
oh if you dont like adding 0. maybe you can use the keyword #:final instead of #:break (they say it does just one more iteration before breaking the loop) On Wednesday, 14 October 2015 05:53:03 UTC+2, Linh Chi Nguyen wrote: > Isnt this the reason we should add 0 at the beginning of the list? > > On 13/ott/2015, at 22:38, Matthias Felleisen 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 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?) > >> -- 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.
Re: [racket-users] help on coding finite state automata
Isnt this the reason we should add 0 at the beginning of the list? On 13/ott/2015, at 22:38, Matthias Felleisen 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 > 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 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 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 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, 2
Re: [racket-users] Long-term Runtime session state
> I just never found any good docs on how to do that. Near as I can tell, runtime linking of a unit is even MORE verbose and persnickety than just > manually typing in all the procedures you want to pass to a callback Some of the verbosity of units can be reduced using the "inference" features that Racket's unit system provides. Here's one way to do this: ;; define a signature that contains info about your runtime data (define-signature runtime-data^ (runtime-value)) ;; define a unit that encapsulates the initialization of data you need at runtime (define-unit runtime-data@ (import) (export runtime-data^) (define runtime-value ...)) ;; Implement the rest of your program in a unit which imports the runtime-data^ signature (define-unit use-runtime-data@ (import runtime-data^) (export) ;; your main program code goes here ... ) ;; link together the units to run your program (invoke-unit/infer (link runtime-data@ use-runtime-data@)) There is still some syntactic overhead, but using unit inference does alleviate many of the confusing parts of manually linking and invoking units. Dan On Tue, Oct 13, 2015 at 7:07 PM, Nota Poin wrote: > On Tuesday, October 13, 2015 at 11:40:12 PM UTC, Alexis King wrote: > > units > > Oh uh, conceivably you could have "code" that provided a live session > object on linking, and handled session refreshing internally, then just > link that with units that have session dependant code. I just never found > any good docs on how to do that. Near as I can tell, runtime linking of a > unit is even MORE verbose and persnickety than just manually typing in all > the procedures you want to pass to a callback. > > -- > 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.
Re: [racket-users] Long-term Runtime session state
On Tuesday, October 13, 2015 at 11:40:12 PM UTC, Alexis King wrote: > units Oh uh, conceivably you could have "code" that provided a live session object on linking, and handled session refreshing internally, then just link that with units that have session dependant code. I just never found any good docs on how to do that. Near as I can tell, runtime linking of a unit is even MORE verbose and persnickety than just manually typing in all the procedures you want to pass to a callback. -- 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.
Re: [racket-users] Long-term Runtime session state
I usually prefer to do something like for the `roomba` object in "http://www.neilvandyke.org/racket-roomba/";. See how there's a `current-roomba` Racket parameter, which provides a default value for the `#:roomba` optional argument for each procedure. So, users of the code can pass around the `roomba` object explicitly, or they can be more terse/lazy, and let the parameter be used. There's also a `with-roomba` syntax form, as a convenience. `with-roomba` does the `open-roomba`, `close-roomba`, and `(parameterize ((current-roomba ...)) ...)`. (If you're micro-optimizing, you might decide you don't want to be passing around the `roomba` object as an argument all the time, nor doing parameter referencing. But most code has many bigger things to optimize before that.) Neil V. -- 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.
Re: [racket-users] Long-term Runtime session state
On Tuesday, October 13, 2015 at 11:40:12 PM UTC, Alexis King wrote: > Have you taken a look at parameters? Short answer: yes. Long answer: they're convenient thread-local globals, but still feel like globals to me. (define a (make-parameter 0)) (define (called-at-hopefully-regular-intervals) (a (+ (a) 1)) (define (something-stupid) (let ((b (a))) (totally-innocuous-event-loop) (+ 3 b b b))) A local variable session doesn't require me to for the internal implementation, write a bunch of abstraction-rich difficult-to-optimize inscrutable state code, whereas with parameters I always have to (call) them just in case their value just changed. It's like parameters force the internal stuff to use the careful, externally exposed interface to access their own internal data. -- 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.
Re: [racket-users] Long-term Runtime session state
Have you taken a look at parameters? http://docs.racket-lang.org/guide/parameterize.html http://docs.racket-lang.org/reference/parameters.html There is also a way to “link units at runtime”, conveniently called “units”. http://docs.racket-lang.org/guide/units.html?q=unites#%28tech._unit%29 http://docs.racket-lang.org/reference/mzlib_unit.html Of course, those probably aren’t quite what you’re looking for (they’re mostly for linking units of *code* together at runtime). The usual solution to the problem you describe is Racket’s parameters. > On Oct 13, 2015, at 4:36 PM, Nota Poin wrote: > > How do you deal with long-term state that your programming logic depends on, > but is only available at run-time? A persistent connection to a database, or > an RPC server for instance, or a logged in user account. Do you use > parameters? Session objects? Just raw globals? Or something stranger? > > This might be a crazy idea (probably is) but what I tried doing is > initializing state as a local variable, then instead of passing it like an > object, passing methods that use it directly as functions. The idea is to > have something like a module, but whose code cannot fully compile until the > session has been established. > > so like, > (define (sess cb) > (let ((thing (make-session))) > (cb >(lambda (arg) > (+ thing 23 arg)) >(lambda () > (do-things-with thing) > (sess (lambda (foo bar) (foo) (if (bar) ...))) > > Keeping track of the order of these passed functions gets confusing though, > when you try to extend one session-aware module-thingy with another. Now you > have to write all the functions passed to the “base” wrapper in the extending > wrapper, and make sure they’re all in order, and nothing’s missing. Using > keywords for everything would fix that, but is there a more elegant way to do > it? There's little documentation I can find about linking units at run-time. > > -- > 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.
[racket-users] Long-term Runtime session state
How do you deal with long-term state that your programming logic depends on, but is only available at run-time? A persistent connection to a database, or an RPC server for instance, or a logged in user account. Do you use parameters? Session objects? Just raw globals? Or something stranger? This might be a crazy idea (probably is) but what I tried doing is initializing state as a local variable, then instead of passing it like an object, passing methods that use it directly as functions. The idea is to have something like a module, but whose code cannot fully compile until the session has been established. so like, (define (sess cb) (let ((thing (make-session))) (cb (lambda (arg) (+ thing 23 arg)) (lambda () (do-things-with thing) (sess (lambda (foo bar) (foo) (if (bar) ...))) Keeping track of the order of these passed functions gets confusing though, when you try to extend one session-aware module-thingy with another. Now you have to write all the functions passed to the “base” wrapper in the extending wrapper, and make sure they’re all in order, and nothing’s missing. Using keywords for everything would fix that, but is there a more elegant way to do it? There's little documentation I can find about linking units at run-time. -- 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.
Re: [racket-users] Re: Case for net/url.rkt to read HTTP proxy servers from environment
On Tuesday, October 13, 2015 at 9:21:08 PM UTC+2, William Hatch wrote: > I would like to see it fall back on HTTP_PROXY if PLT_HTTP_PROXY is not found. +1 > It is annoying that the cases vary (eg. wget uses http_proxy and https_proxy, > curl uses http_proxy and HTTPS_PROXY), but maybe we could prefer the one in > all caps and fall back on lowercase. To be sure, for HTTP both wget and curl (and not only) agree on `http_proxy`. Before today I had always only seen (on Linux) the lowercase variant, also for other ones (e.g. https://wiki.archlinux.org/index.php/Proxy_settings#Environment_variables, https://askubuntu.com/questions/228530/updating-http-proxy-environment-variable, http://www.cyberciti.biz/faq/linux-unix-set-proxy-environment-variable/). On Tuesday, October 13, 2015 at 9:21:08 PM UTC+2, William Hatch wrote: > It doesn’t use the standard HTTP_PROXY and NO_PROXY from the environment, > since > I want to be able to control the proxies for Racket obviously and separately > from the rest of the environment. But (I'd guess, like William Hatch) most users would want to set those at once. If I were writing a patch and I wanted special proxies for Racket, I'd try to support well common use cases (reading `http_proxy`), and only add extra code for other cases if they're widespread enough. Changing a variable before starting specific command is not hard per se, and it's not hard to have some alias for it: `http_proxy=$PLT_HTTP_PROXY racket ...` -- 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.
Re: [racket-users] help on coding finite state automata
:( . I tried few modifications, but I didn't get any improvement. I think that the recalculation of the population is used very seldom, so any change there will not affect the speed too much. Most of the time is used in the matches, but I don't have any suggestion for it (that doesn't include uglifying the code, and perhaps are also not useful). Gustavo On Mon, Oct 12, 2015 at 7:14 PM, Matthias Felleisen wrote: > > > So I couldn't resist and wrote the vector-based, allocation-minimizing > version of the program. I didn't get that much of a performance gain. > > I might still change the fitness representation (into a vector) or > integrate it into 'population' (where it belongs from an SE perspective). > I doubt this will do much better in terms of speed. A speed-up of 6x > will have to do for now. > > Code at the same old link: > >>https://github.com/mfelleisen/sample-fsm > > > > > > > > On Oct 12, 2015, at 11:46 AM, Matthias Felleisen wrote: > >> >> 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 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.
Re: [racket-users] help on coding finite state automata
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 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 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 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 >>> 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 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,
Re: [racket-users] help on coding finite state automata
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 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 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 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 >>> 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. ot
Re: [racket-users] Re: Case for net/url.rkt to read HTTP proxy servers from environment
I would like to see it fall back on HTTP_PROXY if PLT_HTTP_PROXY is not found. It is annoying that the cases vary (eg. wget uses http_proxy and https_proxy, curl uses http_proxy and HTTPS_PROXY), but maybe we could prefer the one in all caps and fall back on lowercase. My last job was behind a proxy, and it was so annoying to have to figure out how to get every program to use a proxy. So falling back on the (more or less) standard environment variables would be really helpful so end users of racket programs have less to configure to have things "just work". On Mon, Oct 12, 2015 at 8:19 AM, Tim Brown wrote: > I’ve just created PR: > PLT_HTTP_PROXY and PLT_NO_PROXY honoured #1089 > > It doesn’t use the standard HTTP_PROXY and NO_PROXY from the environment, > since > I want to be able to control the proxies for Racket obviously and > separately > from the rest of the environment. > > It’s kinda tested, and only documented in the PR at the moment. > > Could someone form an opinion of this PR for me :-) > > Thanks, > > Tim > > On Friday, October 9, 2015 at 2:39:26 PM UTC+1, Tim Brown wrote: > > Is there any merit in taking the current environment variable values > > (on UNIX at least) of “proxy”, “http_proxy” and “https_proxy” and > > loading them by default into current-proxy-servers? (net/url.rkt l.26) > > > > Are these even the right variables to go for? > > > > What do we think? > > > > Tim > > > > -- > > Tim Brown CEng MBCS > > > > City Computing Limited · www.cityc.co.uk > > City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB > > T:+44 20 8770 2110 · F:+44 20 8770 2130 > > > > City Computing Limited registered in London No:1767817. > > Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE > > VAT No: GB 918 4680 96 > > -- > 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.
Re: [racket-users] help on coding finite state automata
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 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 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 >> 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 outs
Re: [racket-users] help on coding finite state automata
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 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 > 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 m
Re: [racket-users] help on coding finite state automata
See repo. I special-purposed shuffle for my data rep. On Oct 13, 2015, at 12:39 PM, Alex Knauth wrote: > I've started on that, but shuffle doesn't exist properly yet for generic > collections. I could just use (shuffle (sequence->list )), but, what > would be the best way of representing this? Generic collections give you the > freedom of creating a new type of data structure just for shuffled sequence, > so would it be best to do that, or something else? > >> On Oct 12, 2015, at 7:45 PM, 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.) >> >>> On Oct 12, 2015, at 7:37 PM, Alex Knauth wrote: >>> >>> What about Alexis King's persistent vectors? > > -- > 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.
Re: [racket-users] help on coding finite state automata
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 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.
Re: [racket-users] Puzzle
2015-10-13 19:16 GMT+02:00 Matthew Flatt : > At Tue, 13 Oct 2015 19:10:54 +0200, Jens Axel Søgaard wrote: > > I think I get it - if sort is a macro. > > The `define` form that supports keyword arguments can expand to a macro > definition. As an example, try the macro stepper on > > #lang racket/base > (define (f #:x x) x) Got it! (btw - that example has a surprisingly large expansion) Thanks, Jens Axel -- 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.
Re: [racket-users] Puzzle
At Tue, 13 Oct 2015 19:10:54 +0200, Jens Axel Søgaard wrote: > 2015-10-12 14:48 GMT+02:00 Matthew Flatt : > > > At Mon, 12 Oct 2015 13:23:48 +0200, Jens Axel Søgaard wrote: > > > In DrRacket with just #lang racket in the definitions window. > > > Click Run. > > > > > > Welcome to DrRacket, version 6.3.0.1--2015-10-12(a683542/a) [3m]. > > > Language: racket; memory limit: 1024 MB. > > > > > > > (syntax->datum (expand #'(begin (define (sort v) v) (sort t > > > '(begin (define-values (sort) (lambda (v) v)) (#%app sort9 t)) > > > > > > Notice that the identifiers sort and sort9 in the expansion are > > different. > > > > > > Why? > > > > The `sort` binding exported from `racket/base` is a macro that expands > > to `sort9`. The use of `sort` in the right-hand side of the definition > > refers to that binding, instead of the `sort` being defined, because > > the top level is hopeless. > > > > I think I get it - if sort is a macro. > > However I checked the sort in list.rkt and the one in sort.rkt > (by letting DrRacket opening the defining files) and both > seem to define sort as a function. The `define` form that supports keyword arguments can expand to a macro definition. As an example, try the macro stepper on #lang racket/base (define (f #:x x) x) -- 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.
Re: [racket-users] Puzzle
2015-10-12 14:48 GMT+02:00 Matthew Flatt : > At Mon, 12 Oct 2015 13:23:48 +0200, Jens Axel Søgaard wrote: > > In DrRacket with just #lang racket in the definitions window. > > Click Run. > > > > Welcome to DrRacket, version 6.3.0.1--2015-10-12(a683542/a) [3m]. > > Language: racket; memory limit: 1024 MB. > > > > > (syntax->datum (expand #'(begin (define (sort v) v) (sort t > > '(begin (define-values (sort) (lambda (v) v)) (#%app sort9 t)) > > > > Notice that the identifiers sort and sort9 in the expansion are > different. > > > > Why? > > The `sort` binding exported from `racket/base` is a macro that expands > to `sort9`. The use of `sort` in the right-hand side of the definition > refers to that binding, instead of the `sort` being defined, because > the top level is hopeless. > I think I get it - if sort is a macro. However I checked the sort in list.rkt and the one in sort.rkt (by letting DrRacket opening the defining files) and both seem to define sort as a function. https://github.com/racket/racket/blob/master/racket/collects/racket/private/list.rkt#L40 https://github.com/racket/racket/blob/master/racket/collects/racket/private/sort.rkt /Jens Axel -- 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.
Re: [racket-users] help on coding finite state automata
I've started on that, but shuffle doesn't exist properly yet for generic collections. I could just use (shuffle (sequence->list )), but, what would be the best way of representing this? Generic collections give you the freedom of creating a new type of data structure just for shuffled sequence, so would it be best to do that, or something else? > On Oct 12, 2015, at 7:45 PM, 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.) > >> On Oct 12, 2015, at 7:37 PM, Alex Knauth wrote: >> >> What about Alexis King's persistent vectors? -- 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.
Re: [racket-users] help on coding finite state automata
> > - why you use [i (in-range 10)] in all for loop? what's the difference > with [i 10]. they both produce stream, right? Yes, but `in-range` runs faster because of "types". Here's a little example: #lang racket/base (define N (expt 10 7)) (time (for ([n (in-range N)]) (void))) ;; cpu time: 36 real time: 36 gc time: 0 (time (for ([n N]) (void))) ;; cpu time: 635 real time: 635 gc time: 0 -- 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.
Re: [racket-users] help on coding finite state automata
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.
Re: [racket-users] setting default font face and size for a text%
On Mon, Oct 12, 2015 at 09:08:45AM -0500, Robby Findler wrote: > That will work for newly typed text. Other code might changed the style and > copying and pasting styled text may change it. You can use after-insert to > change the style for those cases. Or maybe you want to allow that. OK thanks. > There is also, in the framework, editor:standard-style-list which uses a > global style list and drracket mutates its "Stabdard" style for font > selection and sizes and whatnot. This brings up another question... I've been aware of the framework, but thus far have not investigated it significantly. Is there a high level guide somewhere that describes when to use the framework versus just racket/gui directly? Does anyone know of non-PLT applications using the framework? David -- 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.
