| dancor | when is 6.8 coming out, or is haskell' next |
| allbery_b | I think H' and ghc are disjoint |
| jcreigh | but seriously, a debugger sounds cool. I can't quite picture how you'd present the (nearly) endless repeating unwrapping of thunks in any reasonable manner... |
| allbery_b | (except insofar as much of H' simply ratifies ghc...) |
| sorear | > let evolve f st = (let pool = take 50 $ sortBy (comparing f) st in replicateM 100 (do a <- State (randomR (0,49)) ; b <- State (randomR (0,49)) ; return (((pool!!a) + (pool!!b))/2))) ; minimize f = do { gn <- replicateM 100 (State random) ; foldM (flip . const $ evolve f) gn [1..100] ; return (minimumBy (comparing f) gn) } in evalState (minimize (\x -> (x - cos x) ^ 2)) (mkStdGen 42) |
| lambdabot | 0.7680036230636769 |
| sorear | > let evolve f st = (let pool = take 50 $ sortBy (comparing f) st in replicateM 100 (do a <- State (randomR (0,49)) ; b <- State (randomR (0,49)) ; return (((pool!!a) + (pool!!b))/2))) ; minimize f = do { gn <- replicateM 100 (State random) ; foldM (flip . const $ evolve f) gn [1..100] ; return (maximumBy (comparing f) gn) } in evalState (minimize (\x -> (x - cos x) ^ 2)) (mkStdGen 42) |
| lambdabot | 1.111927198039353e-2 |
| sorear | > let evolve f st = (fmap (sortBy (comparing f)) $ replicateM 100 (do a <- State (randomR (0,49)) ; b <- State (randomR (0,49)) ; return (((st!!a) + (st!!b))/2))) ; minimize f = do { gn <- replicateM 100 (State random) ; foldM (flip . const $ evolve f) gn [1..100] ; return (maximumBy (comparing f) gn) } in evalState (minimize (\x -> (x - cos x) ^ 2)) (mkStdGen 42) |
| lambdabot | 1.111927198039353e-2 |
| sorear | > let evolve f st = (fmap (sortBy (comparing f)) $ replicateM 100 (do a <- State (randomR (0,49)) ; b <- State (randomR (0,49)) ; return (((st!!a) + (st!!b))/2))) ; minimize f = do { gn <- replicateM 100 (State random) ; foldM (flip . const $ evolve f) gn [1..100] ; return (gn!!0, gn!!99) } in evalState (minimize (\x -> (x - cos x) ^ 2)) (mkStdGen 42) |
| lambdabot | (0.11040701265689151,0.8744269547458801) |
| dancor | does something like Data.ByteString.hGet >>= Data.Binary.decode :: Int magically block just until enough data to make an int has come in? |
| sorear | > let evolve f st = (fmap (sortBy (comparing f)) $ replicateM 100 (do a <- State (randomR (0,49)) ; b <- State (randomR (0,49)) ; return (((st!!a) + (st!!b))/2))) ; minimize f = do { gn <- replicateM 100 (State random) ; foldM (flip . const $ evolve f) gn [1..30] ; return (gn!!0, gn!!99) } in evalState (minimize (\x -> (x - cos x) ^ 2)) (mkStdGen 42) |
| lambdabot | (0.11040701265689151,0.8744269547458801) |
| sorear | dancor: no |
| dancor | sorear: what is the best way to achieve that |
| sorear | actually... dancor: what kind of handle are you using? socket? file? |
| dancor | socket |
| sorear | it should work then it does large block reads, but in the case of sockets the reads always return when data is recieved |
| chessguy | hi haskellers sorear, what's this evolve function you're writing? |
| sorear | files OTOH will probably block until the whole block is read |
| jcreigh | hi chessguy |
| dancor | sorear: what if you wanted it to work with any Handle |
| sorear | dancor: then you'd have to fudge it to read 4 bytes at a time rather than 16384 dancor: but files etc don't block indefinitely unless your drive has crashed |
| dancor | sorear: ok, so even with files it would still work, just waiting on the normal file read |
| sorear | yeah |
| dancor | sorear: and if an integer spanned two blocks sorear: it would do the second one without death? |
| sorear | dancor: then the Binary code would immediately try to access the next chunk in the lazy bytestring, thus causing more of the hGet to be evaluated, thus reading another block of data. laziness++ |
| dancor | yay it's delicious |
| narain | i remember seeing a new prelude-like module people had written and/or were discussing, and i can't find it now |
| sorear | @wiki The_other_prelude |
| lambdabot | http://www.haskell.org/haskellwiki/The_other_prelude |
| sorear | ? |