[llvm-commits] patch: chrec * chrec = chrec.

[Nick Lewycky]

Joerg Sonnenberger wrote:
> On Mon, Oct 03, 2011 at 02:10:45PM -0700, Nick Lewycky wrote:
>> On 3 October 2011 13:51, Joerg Sonnenberger<joerg at britannica.bec.de>  wrote:
>>> What exactly is the desired behavior in case of overflow?
>>> E.g. do you want to get C(n,k) % (UINTMAX + 1)? In that case, your
>>> formula doesn't compute correct results.
>>>
>>
>> In overflow the return value is garbage and Overflow is set. This method
>> deserves a comment.
>
>> From IRC: since n is supposed to be small, it might be better to just
> check for n<= 34 and consider it as overflow otherwise. Essentially,
> that's the largest number for which C(2n,n)<  2**32. In theory, it would
> be possible to compute C(n,k) in the finite field by eliminating the
> factors 2 in the divisor and implementing the division using the
> multiplicative inverse at the end. That's quite a bit more work though.

I tried the simple trick of pulling out 2's before the multiple/divide 
in Choose() and that only helped a little; in all the cases I could 
find, the actually loop optimization being performed was guaranteed to 
overflow on some other Choose(n, k) computation it would do later.

It's not clear to me how using multiplicative inverses helps? Can I take 
each term in the denominator (the terms in k!) and take the inverse of 
each, and just turn them all into multiplies?

For now I'm planning to go ahead with the implementation of Choose() 
as-is, then we can change it in subsequent patches.

Nick