[Numpy-discussion] Reminder: code freeze for bet at the end of the WE

josef.pktd@gmai... josef.pktd@gmai...
Sat Mar 14 14:37:03 CDT 2009


On Sat, Mar 14, 2009 at 3:11 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> Hi Josef,
>
> On Sat, Mar 14, 2009 at 12:14 PM, <josef.pktd@gmail.com> wrote:
> <snip>
>
>>
>> {{{
>> import numpy as np
>>
>> assert np.all(np.random.hypergeometric(3,18,11,size=10) < 4)
>> assert np.all(np.random.hypergeometric(18,3,11,size=10) > 0)
>>
>> pr = 0.8
>> N = 100000
>> rvsn = np.random.logseries(pr,size=N)
>> # these two frequency counts should be close to theoretical numbers
>> with this large sample

Sorry, cut and paste error, the second case is k=2
for k=1 the unpatched version undersamples, for k=2 the unpatched
version oversamples, that's the reason for the inequalities; the
bugfix should reallocate them correctly.

for several runs with N = 100000, I get with the patched version

>>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==1) / float(N)
in range:  0.4951, 0.4984    # unpatched version is too small

>>> rvsn = np.random.logseries(pr,size=N); np.sum(rvsn==2) / float(N)
 in range:  0.1980, 0.2001  # unpatched version is too large

with constraints a bit more tight, it should be:

>> assert np.sum(rvsn==1) / float(N) > 0.49   # theoretical:  0.49706795
>> assert np.sum(rvsn==2) / float(N) < 0.205   # theoretical:  0.19882718

Josef

>> }}}
>
> I just see one frequency count here. Do you mean that the frequency count
> should fall in that range with some probability?
>
> Chuck
>


More information about the Numpy-discussion mailing list