4 ms·
Golang map iteration is returned in random order specifically to make sure that people don't rely on the order. I think this feature says a lot about the philo
by _whiteCaps_ 7y ago
Golang map iteration is returned in random order specifically to make sure that people don't rely on the order.
I think this feature says a lot about the philosophy of Python vs Go.
- MereInterest 7y agoSounds like a fast and idiomatic way to shuffle a deck of cards is then to convert to a map and back.
- kragen 7y agoNo, it isn't random enough for that.
- jarekkruk 7y agoIIRC it used to just start iteration at a pseudorandom index and then iterate normally. I looked at it couple years ago, don't know if they changed it.
- kragen 7y agoIt seems to do that, but I think it also tweaks the hash function for each newly created map, because in the code linked from https://news.ycombinator.com/item?id=22278753 https://news.ycombinator.com/item?id=22278753 I'm not getting rotations of the same iteration order when I generate two maps. There doesn't seem to be any randomness in mapiternext() itself. You could imagine that the hash function itself might do an adequate job of randomizing the order of the cards, though, especially if salted with a per-map salt. SipHash, for example, would probably not have any detectable biases in the distribution of the permutations thus produced. But whatever hash function Golang is using for my structs has an easily visible bias, as described in that comment.
- thedirt0115 7y agoConvert a deck of cards ([]Card?) to a map (map[Card]bool?) and back just to shuffle? That's unlikely to be faster or more idiomatic than a straightforward implementation of the Fisher-Yates shuffle[1]. Try writing the code to do it both ways and compare. [1]: https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle
- kragen 7y agoI think "idiomatic" would be using rand.Perm, which implements the Fisher%E2%80%93Yates shuffle. But aside from whether it's idiomatic, converting to a map isn't random enough.
- kragen 7y agoWith Golang 1.11, I get orderings like this. S is spades, H is hearts, D is diamonds, and C is clubs, because HN eats the Unicode characters I was actually using. S9 SJ SK HQ D9 S4 S5 S10 HJ S8 H6 DA D2 D4 DQ C6 C8 CJ H3 H9 DK C3 CQ SA S2 S3 S6 SQ H4 H10 D8 D10 C4 CK S7 H7 D5 D6 D7 C7 H2 HK D3 DJ C2 C5 C9 HA H5 H8 CA C10 On average you would expect about one card in a shuffled deck to be (cyclically) followed in the deck by its succeeding card, and on about one out of 50 shuffles, that card would be followed by its successor. Here we have S4 S5, DA D2, SA S2 S3, and D5 D6 D7. This is very strong evidence of bias. I'm interested to hear if my Golang can be made more idiomatic, or if there are bugs in it: http://canonical.org/~kragen/sw/dev3/mapshuffle.go http://canonical.org/~kragen/sw/dev3/mapshuffle.go In particular it seems like there ought to be a less verbose way to express the equivalent of the Python list({card: True for card in deck}) in Golang.
- gowld 7y agoWhat does it say? That Python is willing to spend more computation time for simplicity, without waiting for the programmer to ask for it? That Python will make semantic changes in minor version bumps of the language?
- jwkane 7y agoThe new-ish ordered dictionary is actually faster. It is also completely backward compatible for any but the most contrived example. Now wasting computation on randomizing... that is a problem.