Michael,
thank you very much for your suggestions.
> 1) Do you really need to get the p value to 4 decimals? If you changed
> qui gen double p = (_n-1)/10001 to qui gen double p = (_n-1)/1001
> Then you have a 90% reduction in some of the calculations.
You are correct, there is a substantial reduction in computing time if
the number of calculation points is lowered. I tried a few
configurations and found that anything lower than 2500 does not
produce accurate results any longer; but already at 2500 the code is
running much faster.
> 2) I don't know much about this test, but wouldn't the optimum point be a smooth
> function of p?
Yes, it is a smooth function. I am not quite sure how to implement an
iterative approach; however, one can limit the search to the 99.9%
confidence interval of the true value of p. In many cases, this will
exclude a good part of the [0,1] interval. In the example I gave, the
confidence interval is [0.008,0.083]. Therefore, implementing an
option to compute the confidence interval adjusted version of the test
reduces execution time significantly.
> 3) Don't use tabi. -tabi- requires a preserve and has a lot of ado machinery to
> set up the desired table. It ends up creating a dataset with RxC observations
> and a frequency weight variable that contains the counts. You could instead
> hardwire a 2x2 table with values for row, col, and fw. A loop would then just
> change the fw values to cycle through all of the n1 and n2 values.
Thanks for this tip; I had a look at -tabi- and mimicked what it does
in my program, in exactly the way you pointed out. While it makes the
code faster, the speed improvement is not very big.
After implementing all these changes I can compute the ci adjusted
version of the test in a very reasonable time.
Thanks again for your many helpful suggestions.
Eva
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
