And the winners are... : comments [Peter]

On the other hand, the simulation approach is worthwhile as a check, because it's easier to be sure there weren't any cock-ups like forgetting to square or square-root something.

(Actually, I'm faintly suspicious of the Monte Carlo result quoted above. I haven't actually done the chi-squared calculations, but it's so close to the correct answer that my instinct is to suspect a randomness problem!)

[parent entry] [link] [parent] [reply]

Yeah. That many significant figures... Let's try a second run

Python 2.5.2 (r252:60911, Jun  6 2008, 23:32:27)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> sum([random.normalvariate(69.3, 2.92) > random.normalvariate(64.1, 2.75) for i in range(10000000)])
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'random' is not defined
>>> import random
>>> sum([random.normalvariate(69.3, 2.92) > random.normalvariate(64.1, 2.75) for i in range(10000000)])
9026585
>>> sum([random.normalvariate(69.3, 2.92) > random.normalvariate(64.1, 2.75) for i in range(10000000)])
9026391
>>> sum([random.gauss(69.3, 2.92) > random.gauss(64.1, 2.75) for i in range(10000000)])
9025517

Hmmm, looks like a co-incidence to me.

Quite why the python module has two functions for generating random numbers from a gaussian I don't know...

Edited (Removed an accidentally duplicated line) Date: 2010-05-06 12:39 pm (UTC)

[link] [parent] [reply]

Ooh, I hadn't noticed before that DW notifications about comments having been edited include a comment saying what was changed. That's pretty cool.

normalvariate vs gauss: poking at the source code it looks as if they use different generation methods, so presumably there's some tradeoff of performance against accuracy which power users might plausibly care about. The documentation doesn't bother to say what, though; it only mentions that gauss() "is slightly faster".

(Also, gauss() is apparently undocumentedly non-thread-safe! It uses a method that generates two independent normal variates in one go, so it caches the second one and returns it from the next call. The comments in the code mention that you should therefore do some locking if you want to use gauss() in multiple threads on the same underlying random state, but somehow that doesn't seem to have found its way into the docs. Good grief.)

[link] [parent] [reply]

it caches the second one and returns it from the next call

A while ago it had the problem that this caching didn't pay attention to re-seeding the RNG, and so you could do

>>> random.seed(10)
>>> random.gauss(0,1)
-0.95371700806333715
>>> random.seed(10)
>>> random.gauss(0,1)
-0.95371700806333715

and get a different answer the second time - an alternating pattern of two answers in fact. Evidently this has been fixed.

[link] [parent] [reply]

Sun	Mon	Tue	Wed	Thu	Fri	Sat
						1
2	3	4	5	6 1	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Peter

(no subject)

(no subject)

(no subject)

(no subject)

March