Binomial sampling: limit max n and use powi

[dhardy]

Fix #747

@vks I know you didn't favour this approach, but it does fix the test.

(Any idea why the pow method is generating incorrect results? Apparently pow(0.7, 20) = 0.0000459986536544739.)

[vks]

Would it make sense to make n a u32 instead? (However, this would be a breaking change.) With this PR, I think it might be unfortunate that for tiny p and n > i32::MAX the slow path is used. On the other hand, I'm not sure people want to sample the binomial distribution for such large n.

Any idea why the pow method is generating incorrect results? Apparently pow(0.7, 20) = 0.0000459986536544739.

Which method? The implementation currently used in Rand seems to return the correct result.

[dhardy]

It does seem unfortunate, but is likely quite a rare case that n is over 2 billion.

Also note that this method calculates q = 1 - p which will be inaccurate with very small p due to the limited size of the mantissa (53 bits). n*p < 10 and n >= 2**31 implies |n| <= 2**-27, which implies at most 53+1-27=27 bits of precision for q IIUC. (Of course small p and small n is still possible.)

Which method?

As mentioned, when run on emulated MIPS through cross, I get this strange result.

[vks]

As mentioned, when run on emulated MIPS through cross, I get this strange result.

Interesting, this likely affects the num_traits implementation as well.

[vks]

I would prefer to fix our pow function on MIPS, but let's merge it for now to fix this weird failure.

[dhardy]

Yes, I double-checked the num_traits code but it looks the same. I also tried replacing all binary arithmetic ops with numeric ones, but it didn't help.

Good call. This is the first all-green build I've seen here in a while!