My guess was right: the difference between exactly 6 and at least 6 is negligible. This is because the events exactly 7, exactly 8, etc, are all extremely unlikely.
The answer is: 0.0000703602.
gm
Quick and dirty java code follows:
<font class="small">Code:</font><hr /><pre>
package test;
import java.math.BigDecimal;
public class Test {
public static void main(String[] args) {
Test test = new Test();
BigDecimal ans = new BigDecimal("0").setScale(50);
for (int i=6; i<=150; i++) {
ans = ans.add(test.exactly(150,i,(1D/221)));
}
System.out.println(ans);
}
public BigDecimal exactly(int n, int r, double p) {
BigDecimal ans = new BigDecimal("1").setScale(50);
BigDecimal n1 = new BigDecimal(new Integer(n).toString() ).setScale(50);
BigDecimal r1 = new BigDecimal(new Integer(r).toString() ).setScale(50);
BigDecimal p1 = new BigDecimal(new Double(p).toString() ).setScale(50);
BigDecimal q1 = new BigDecimal(new Double(1-p).toString() ).setScale(50);
ans = choose(n,r);
int pCount = r;
int qCount = n-r;
while (pCount-- > 0)
ans = ans.multiply(p1);
while (qCount-- > 0)
ans = ans.multiply(q1);
return ans;
}
public BigDecimal choose( int n, int r) {
BigDecimal one = new BigDecimal("1").setScale(50);
BigDecimal ans = new BigDecimal("1").setScale(50);
BigDecimal n1 = new BigDecimal(new Integer(n).toString() ).setScale(50);
BigDecimal r1 = new BigDecimal(new Integer(r).toString() ).setScale(50);
while (r1.compareTo(one) >= 0) {
ans = ans.multiply(n1.divide(r1, BigDecimal.ROUND_HALF_UP));
n1 = n1.subtract(one);
r1 = r1.subtract(one);
}
return ans;
}
}
</pre><hr />