| --- Log opened Fri Sep 08 00:00:49 2017 |
| 00:05 | | Kindamoody is now known as Kindamoody[zZz] |
| 01:04 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has joined #code |
| 01:04 | | mode/#code [+o celticminstrel] by ChanServ |
| 01:27 | | Derakon[AFK] is now known as Derakon |
| 02:05 | | ErikMesoy [Bruker@Nightstar-hq72t5.customer.cdi.no] has quit [Connection closed] |
| 02:06 | | ErikMesoy [Bruker@Nightstar-hq72t5.customer.cdi.no] has joined #code |
| 03:08 | | Jessikat [Jessikat@Nightstar-hejdc4.dab.02.net] has joined #code |
| 03:11 | | Jessikat`` [Jessikat@Nightstar-qck2dv.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 03:38 | | Jessikat` [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 03:50 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 03:53 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 03:53 | | mode/#code [+o Alek] by ChanServ |
| 04:04 | | * Derakon grumbles at his map generator, which is somehow nondeterministic. |
| 04:05 | <&Derakon> | I set a consistent seed at the start, and the code is singlethreaded, so where's the randomness coming from? |
| 04:29 | <~Vornicus> | ...this code I want to see |
| 04:31 | <&McMartin> | Use-before-def bug? |
| 04:34 | <&Derakon> | Okay, this is bizarre. |
| 04:34 | <&Derakon> | random.seed(args.seed) |
| 04:34 | <&Derakon> | print("Seed state: %s" % hash(random.getstate())) |
| 04:34 | <&Derakon> | This prints out different values each time. |
| 04:35 | <~Vornicus> | what is args.seed |
| 04:35 | <&Derakon> | 0 |
| 04:35 | <&Derakon> | I just replaced it with literal 0 and still get variable results. |
| 04:35 | <~Vornicus> | that is strange. |
| 04:36 | <~Vornicus> | If it were None that would explain it |
| 04:36 | <&Derakon> | That might be a bad test though. |
| 04:36 | <&Derakon> | python -c 'import random; random.seed(0); print hash(random.getstate())' |
| 04:36 | <&Derakon> | That's also nondeterministic. |
| 04:37 | <&Derakon> | So I guess setting a specific seed doesn't guarantee a specific random state? |
| 04:38 | <~Vornicus> | no, that should be the right way to do it, hang on |
| 04:38 | <~Vornicus> | what version of python |
| 04:39 | <&Derakon> | 2.7.5. |
| 04:39 | <&Derakon> | Guess I should probably update to whatever the latest 2.7 is, but :effort: |
| 04:40 | <~Vornicus> | I'm getting deterministic results, 2.7.13 |
| 04:43 | <~Vornicus> | >>> import random |
| 04:43 | <~Vornicus> | >>> random.seed(0) |
| 04:43 | <~Vornicus> | >>> hash(random.getstate()) # 1185014853 |
| 04:43 | <~Vornicus> | >>> random.seed(0) |
| 04:43 | <~Vornicus> | >>> hash(random.getstate()) # 1185014853 |
| 04:43 | <&Derakon> | Guess I get to try updating, then. |
| 04:43 | <&Derakon> | In the REPL it is consistent. |
| 04:43 | <&Derakon> | Try the one-liner I pasted. |
| 04:45 | <~Vornicus> | Deterministic, in 2.7.13 and 3.6.1 |
| 04:46 | <&Derakon> | Okay. |
| 04:46 | <~Vornicus> | (3.6.1 gives a different hash but I'm not sure if it's a different seed) |
| 04:46 | <~Vornicus> | (state.) |
| 04:47 | <&Derakon> | As long as it's consistent it shouldn't matter. |
| 04:48 | <~Vornicus> | (both Windows official builds) |
| 04:55 | <&Derakon> | Homebrew finally finished installing 2.7.13, and it's still inconsistent...albeit less so. |
| 04:56 | <&Derakon> | Like, the hash is always -3027... and only the last ~8 digits vary. |
| 04:56 | <&Derakon> | How odd. |
| 04:56 | <~Vornicus> | wtf |
| 04:56 | <&Derakon> | Doesn't help me maintain determinacy though. |
| 04:59 | <~Vornicus> | oh oh |
| 05:01 | <~Vornicus> | Two thoughts: 1. there's a hash xor mask that some builds of python randomize |
| 05:02 | <&Derakon> | Hrm, if I print out random.random() at various points in the program, it prints consistent values. |
| 05:02 | <&Derakon> | ...except at the end? Okay, that narrows it down a bit. |
| 05:05 | <&Derakon> | Oh yeah, I set PYTHONHASHSEED=0, which should deal with that randomized hash thing. |
| 05:06 | <~Vornicus> | Thought 2 was shot down by my examination of the source code of the random module, so never mind that. |
| 05:07 | <~Vornicus> | (the docs say "an object" but the object is a tuple) |
| 05:12 | <&Derakon> | So, I have a function that chooses a terrain generator to apply to the map. Up until this function runs, everything is consistent. |
| 05:12 | <&Derakon> | It has a registry of generators. It creates a copy of the registry, sorts it (by generator name), shuffles it, then goes through the shuffled list in order, to see which generators can work. |
| 05:12 | <&Derakon> | It gets called repeatedly until all tiles in the map are claimed. |
| 05:13 | <&Derakon> | Comparing different runs of the program, after a dozen or so calls of this function, the order of its shuffled list diverges. |
| 05:14 | <~Vornicus> | okay. You are I assume using random.shuffle |
| 05:14 | <&Derakon> | Yes. |
| 05:15 | <&Derakon> | https://pastebin.com/sC95bPE5 |
| 05:15 | <&Derakon> | The function, then two runs |
| 05:15 | <&Derakon> | In this case the random numbers themselves don't diverge, presumably because only one of my terrain generators actually invokes the RNG. |
| 05:16 | <&Derakon> | But the shuffling is still inconsistent. |
| 05:18 | <~Vornicus> | the shuffles are the same |
| 05:18 | <~Vornicus> | the picks are different... |
| 05:18 | <&Derakon> | Oh, so they are. Good point. |
| 05:19 | <&Derakon> | So maybe it's going wrong prior to this point... |
| 05:19 | <&Derakon> | In some way that isn't reflected by the output of random.random(). |
| 05:19 | <~Vornicus> | Interestingly of these two runs, one picks deadsimple and then lock1x1 and the other picks lock1x1 and then deadsimple |
| 05:19 | <&Derakon> | So I'm back to trying to find sources of randomness that aren't the random package itself. |
| 05:20 | <&Derakon> | Ye-es, the two generators are identical except that one requires a lock to exist. |
| 05:20 | <&Derakon> | And the other requires one not to exist. |
| 05:20 | <~Vornicus> | (<3 diff) |
| 05:20 | <&Derakon> | So locks, and possibly therefore doors, are potential issues. |
| 05:20 | <&Derakon> | Yeah, I've just been flipping between the two outputs for a visual diff, but that's hard to do in pastebin. |
| 05:22 | <&Derakon> | Doors themselves appear to be identical across runs. |
| 05:25 | <&Derakon> | Found it. |
| 05:25 | <&Derakon> | remaining_chunks = set(self.chunks) |
| 05:25 | <&Derakon> | while remaining_chunks: |
| 05:26 | <&Derakon> | chunk = random.choice(list(remaining_chunks)) |
| 05:26 | <&Derakon> | That. Right there. |
| 05:26 | <&Derakon> | Converting a set to a list is, apparently, nondeterministic. |
| 05:26 | <~Vornicus> | that would do it! |
| 05:29 | < Mahal> | If you need text compares of any kind, I highly recommend Beyond Compare |
| 05:29 | < Mahal> | by Scooter Software |
| 05:30 | <&Derakon> | I'm used to using diff, usually, but in this case I have a bunch of browser tabs open to view the output both raw and as rendered HTML, so that's easier. |
| 05:30 | <&Derakon> | Alas, mapgen is not entirely deterministic yet, but it's deterministic when loading data from file. |
| 05:30 | <&Derakon> | (Said data being only high-level layout, without terrain generation) |
| 05:31 | <&Derakon> | Something in the high-level layout generator is still awry. I'll find it later. |
| 05:33 | | Derakon is now known as Derakon[AFK] |
| 05:42 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 05:50 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has joined #code |
| 05:50 | | mode/#code [+o celticminstrel] by ChanServ |
| 05:50 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 05:51 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has joined #code |
| 05:51 | | mode/#code [+o celticminstrel] by ChanServ |
| 05:51 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 05:52 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 05:52 | | mode/#code [+o macdjord] by ChanServ |
| 05:55 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 07:14 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 07:22 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 07:22 | | mode/#code [+o himi] by ChanServ |
| 08:52 | | Kindamoody[zZz] is now known as Kindamoody |
| 09:38 | | Jessikat` [Jessikat@Nightstar-0fdjfn.dab.02.net] has joined #code |
| 09:40 | | Jessikat [Jessikat@Nightstar-hejdc4.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 10:12 | | Kindamoody is now known as Kindamoody|afk |
| 10:41 | | Degi [Degi@Nightstar-uc9ip3.dyn.telefonica.de] has joined #code |
| 11:12 | | Jessikat` [Jessikat@Nightstar-0fdjfn.dab.02.net] has quit [[NS] Quit: Bye] |
| 11:55 | | Pi [sid25146@Nightstar-7he56f.irccloud.com] has quit [Connection closed] |
| 11:55 | | Pi [sid25146@Nightstar-7he56f.irccloud.com] has joined #code |
| 11:55 | | mode/#code [+o Pi] by ChanServ |
| 11:55 | | Attilla [sid13723@Nightstar-h2b233.irccloud.com] has quit [Ping timeout: 121 seconds] |
| 11:55 | | Mahal [sid171286@Nightstar-0bi4dv.irccloud.com] has quit [Connection closed] |
| 11:56 | | Mahal [sid171286@Nightstar-0bi4dv.irccloud.com] has joined #code |
| 12:07 | | Jessikat [Jessikat@Nightstar-0fdjfn.dab.02.net] has joined #code |
| 12:08 | < Jessikat> | I hate C++ and how it encourages you to think of weird workarounds instead of doing the obvious thing |
| 12:08 | < Jessikat> | Why can't I just have a function that runs at compile time with types as first class objects |
| 12:08 | < Jessikat> | What's so wrong with that x_x |
| 12:09 | < Jessikat> | Why can't I just call remove_pointer(type(this)) |
| 12:09 | < Jessikat> | And have it return a type |
| 12:09 | < Jessikat> | *grmbl* |
| 12:12 | < Jessikat> | Or possibly value_type(type(this)) |
| 12:12 | < Jessikat> | Something like that |
| 12:13 | < Jessikat> | decltype is part of the solution but I will have to use stupid syntax to do the type function thing |
| 12:13 | < Jessikat> | Still * |
| 12:13 | <@TheWatcher> | Because then the forbidden and arcane machinery keeping Bjarne Stroustrup alive wouldn't get its required quota of programmer anger and frustration |
| 12:13 | < Jessikat> | Why isn't everything just Lisp |
| 12:13 | < Jessikat> | Bjarne's actually a cool dude, I met him once |
| 12:14 | < Jessikat> | Shame that C++ and languages of its type miss what abstraction is for |
| 12:14 | | * macdjord paralizes part of Jessikat's mouth. Now everything is lithps. |
| 12:14 | < Jessikat> | Sanks. |
| 12:15 | < Jessikat> | (McMartin's suggestion a couple years ago to look into Pitney languages in more depth has made me a far better programmer) |
| 12:15 | < Jessikat> | Look into other languages * |
| 12:15 | < Jessikat> | That's quite an autocarrot |
| 12:16 | <@TheWatcher> | Got me; I was googling for it and getting very confused! ;D |
| 12:16 | < Jessikat> | Sometimes I sound very clever because of typos |
| 12:19 | < Degi> | What are pitney languages? |
| 12:21 | < Jessikat> | A marvellously timed typo for other |
| 12:21 | | * TheWatcher laments the lack of Gigantic Arcing Equipment and Complex Exposed Machinery of Indeterminate Purpose but Obvious Significance in the computer world, presses a return key to trigger a vast series of jobs that almost no single person is aware of happening |
| 12:36 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has joined #code |
| 12:36 | | mode/#code [+o celticminstrel] by ChanServ |
| 12:41 | <&[R]> | <Jessikat> Why can't I just call remove_pointer(type(this)) <-- what's wrong with delete and deconstructors? |
| 12:42 | | * macdjord helpfully replaces TheWatcher's machine with an analytical engine for all his clanking mechanical need |
| 12:43 | <&[R]> | Pitney languages? |
| 12:43 | <&[R]> | Oh nm |
| 12:58 | < Jessikat> | Because I want a type I can write a proper macro with |
| 13:00 | <&[R]> | Eh? |
| 13:10 | | celticminstrel [celticminst@Nightstar-pqopqb.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 13:49 | | Attilla [sid13723@Nightstar-h2b233.irccloud.com] has joined #code |
| 13:49 | | mode/#code [+o Attilla] by ChanServ |
| 14:20 | | Jessikat [Jessikat@Nightstar-0fdjfn.dab.02.net] has quit [[NS] Quit: Bye] |
| 14:32 | | Degi [Degi@Nightstar-uc9ip3.dyn.telefonica.de] has quit [Connection closed] |
| 14:33 | | Jessikat [Jessikat@Nightstar-0fdjfn.dab.02.net] has joined #code |
| 14:46 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 14:46 | | mode/#code [+o mac] by ChanServ |
| 14:49 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 14:53 | <&ToxicFrog> | (attn: Jessikat) a paper on the computational linguistics of puns: http://idiom.ucsd.edu/~rlevy/papers/kao-etal-2015-cogsci-puns.pdf |
| 15:11 | < Jessikat> | WAT |
| 16:03 | <@Alek> | that's pretty clever. |
| 16:06 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 16:06 | | mode/#code [+o macdjord] by ChanServ |
| 16:08 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 16:08 | | Jessikat` [Jessikat@Nightstar-8mtkmv.dab.02.net] has joined #code |
| 16:08 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 16:08 | | mode/#code [+o mac] by ChanServ |
| 16:10 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 16:10 | | mode/#code [+o macdjord|slep] by ChanServ |
| 16:11 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 16:11 | | Jessikat [Jessikat@Nightstar-0fdjfn.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 16:12 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Operation timed out] |
| 18:13 | | starkruzr [quassel@Nightstar-jo8sru.fios.verizon.net] has quit [Ping timeout: 121 seconds] |
| 20:34 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 20:37 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 20:37 | | mode/#code [+o Alek] by ChanServ |
| 21:02 | | Jessikat` [Jessikat@Nightstar-8mtkmv.dab.02.net] has quit [[NS] Quit: Bye] |
| 21:19 | | Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 21:52 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code |
| 22:01 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 22:01 | | mode/#code [+o mac] by ChanServ |
| 22:04 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 22:06 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 22:06 | | mode/#code [+o macdjord] by ChanServ |
| 22:08 | | Degi [Degi@Nightstar-uc9ip3.dyn.telefonica.de] has joined #code |
| 22:08 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 22:17 | | * McMartin is presumably one of today's 10,000. https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-s elf-contained-tags/1732454#1732454 |
| 22:17 | <&McMartin> | Of note: "This post has been locked due to the high amount of off-topic comments generated" and the moderator's note after the anchored reply |
| 23:55 | | Kindamoody|afk is now known as Kindamoody |
| --- Log closed Sat Sep 09 00:00:50 2017 |