[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