(crazyinsomniac) Re: (2) Binomial Expansion

[crazyinsomniac]

I take great offense in calling my nCr function horribly inaccurate.

You do say right away that is a valid formula for binomial coefficients, but then you say it's hardly a good one?

It is a formula for calculating r-combinations, not binomial coefficients.

The formula for binomial expansion is:

          n
          _
(x+y)^n = \ C(n,j) * x^(n-j) *y^j
          /
          ¯
          j=0

And btw, it is the definitive formula for calculating r-combinations. It's like saying 4/2 is not the same as 2. While 2 is a better way to write 4/2, not every one recognizes 2 right away, and I feel, for the benefit of the reader of me 'craft', n!/(r!(n-r)! is a better way to go.

As for your function, it is shorter, but a litle mysterious when it comes to the math.

               9!         9*8*7* 6!      9*8*7   504
 nCr(9,3) = ---------   = ----------- = ------ = --- = 84
            3!*(9-3)!     3*2*1*(6!)     3*2*1    6

 which follows from the fact that nCr(n,r) = nCr(n,n-r)

 n!              n!               n!         _    n!
------- = ----------------- = -------------  = ---------
r!(n-r)    (n-r)!(n-(n-r))!   (n-r)!(n-n+r)!   (n-r)!(r)!

This however only works for n>r, as long as n and r are both non-negative integers, but shouldn't be a problem in this case.

As for things being integer, since the input is an integer, it follows that any integer multiple of that integer, will also be an integer.

update:
I give, I give, theory v. practice, there is a difference.

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[tye]

Those formulas are all the same in mathematical terms. But we are talking floating point arithmatic here. Computing the factorials and then dividing is going to introduce errors into the computation for fairly small values of n here.

        - tye (but my friends call me "Tye")

[tilly]

If you want to understand the math, I fully agree with your use of the formula. Furthermore for more complex combinatorial problems, understand how to get those formulas is extremely important.

That said, tye is right as well. While in theory that calculation gets the right answer, in practice it starts to be inaccurate for fairly small numbers. You can get around this by using a big integer package. (Or a language that understands integers of arbitrary size.) But that will be somewhat slow.

If you want to understand this, go with the formula. If you want to calculate it, go with the tricks. If you want to calculate answers to arbitrary problems, be prepared to manipulate big integers and hope that performance doesn't matter.

And if you want an even better example some day, bug me about why you should always use row-reduction to find the inverses of matrices rather than Cramer's formula. (Hint: Think numerically unstable and exponential running time, vs n**3 and much better behaved.)

[tilly]

OK, time to eat some crow.

While Perl no longer display integers without using exponential notation at 18!, when I tried to get a mistake in the display, I couldn't. Except for the fact that Perl did not like displaying large numbers, the results are right.

In retrospect I shouldn't be surprised at this. After all the internal calculation is carried out at a higher accuracy than what is displayed. Since the calculation is pretty short, roundoff errors are not readily visible. And testing this is pretty simple:

#! /usr/bin/perl
my ($n, $m) = @ARGV;
my $ans = fact($n)/fact($m)/fact($n-$m);
my $err = $ans - sprintf("%.0f", $ans);
print "$n choose $m: $ans (error $err)\n";

sub fact {
  my $fact = 1;
  $fact *= $_ for 1..$_[0];
  $fact;
}

To find a disagreement between theory and practice I had to go to 28 choose 14. Which was off from being an integer by about 1 part in a hundred million.

Sorry tye, but I find that error tolerable. For a simple example the formula works in this case, even though theoretically in practice it should show some difference between theory and practice.

OTOH I can guarantee you that trying to invert a 10x10 matrix using Cramer's formula is going to be a better example. For an nxn matrix you get n! terms being added and subtracted from each other. It doesn't take a large n to make that rather slow, and to get insane roundoff errors...

[tye]

I stand by my (quite conservative) statement. It does introduce errors for fairly small values of n. It is also at least twice as slow (it can be orders of magnitude slower).

But the greatest weakness to my mind is the following output:

200 choose 1: 200 vs. -1.#IND (1.#QNAN).
        Rate  easy  nice
easy  1464/s    --  -96%
nice 34687/s 2270%    --

Now that is quite a large error term, don't you think?

Yes, there is a useful space over which its accuracy is quite good (though not always as good), and thanks for exploring that.

Here is the code I used:

#!/usr/bin/perl -w
use strict;
use Benchmark qw( cmpthese );
sub fact {
  my $fact = 1;
  $fact *= $_ for 1..$_[0];
  return $fact;
}
sub nice {
  my ($n, $r) = @_;
  my $res = 1;
  for my $i (1..$r) {
    $res *= $n--;
    $res /= $i;
  }
  return $res;
}
while(  <>  ) {
    my( $n, $m )= split ' ';
    my $nice= nice($n,$m);
    my $easy= fact($n)/fact($m)/fact($n-$m);
    print "$n choose $m: $nice vs. $easy (",abs($nice-$easy),").\n";
    cmpthese( -3, {
        nice=>sub{nice($n,$m)},
        easy=>sub{fact($n)/fact($m)/fact($n-$m)},
    } );
}

        - tye (but my friends call me "Tye")

[ariels]

Perl computes floating-point using doubles, which typically have a 48 bit mantissa. 4-byte ints have just 32 bits of precision, so it's natural that doubles have a larger integer range than ints! So you can pretend Perl has 48-bit integers for most purposes.

It's still not a good idea to compute huge numbers and try to cancel them out. Especially when not doing this takes fewer operations.