Thanks Harlan. It's nice to get a feel from other systems.
Seems to me that taking the Mod of two positive numbers and returning a
negative number just isn't right.
But...you did say that Mod has problems! :0
=MOD(COMBIN(9,3),1)
-1.42109E-14

Anyway, thanks for the hint on the size of the error. I should have known
better.
I know this is not related to Excel, but in Mathematica...

The machine error of this calculation is:

MachineError[Binomial[9., x], x - 3.]
5.*Ulps

The machine error with Windows is 5 "Units in the last place, or Ulps"
And like you said, on my windows machine, a unit near 84 is

Ulp[84]
1.4210854715202004*^-14

Therefore, the machine error on my system for this calculation is:

5*Ulp[84]
7.105427357601002*^-14

which is the error I get...
Binomial[9., 3.] - 84
7.105427357601002*^-14

Mod[Binomial[9., 3.], 1]
7.105427357601002*^-14

As a side note, if I use the definition of Combin, I get much smaller
machine errors.
Even Excel returns True here.
=FACT(9)/(FACT(3)*FACT(9-3))-84=0

But this returns False as mentioned befo
=COMBIN(9,3)-84=0
Go figure???
--
Dana DeLouis

"Harlan Grove" wrote in message
ups.com...
Dana DeLouis wrote...
...
Don't know if the following is interesting.
In math programs, Excel's Combin function is called "Binomial."

In Mathematica. There's no equivalent in MathCAD. In GNU Octave, a
MatLab clone, the function is bincoeff, and

printf ("%.16g\n", bincoeff(9,3) - 84);

returns 0 while

printf ("%.16g\n", exp(gammaln(10) - gammaln(4) - gammaln(7)) - 84);

returns -1.4210854715202e-14.

But let's compare apples to apples. In OpenOffice Calc,

=(COMBIN(9;3)-INT(COMBIN(9;3)))

returns 0, while the comparable formula in Gnumeric returns 0, but it
returns the same fractional result as in Excel when used as a term in
longer formulas. The comparable formula in Lotus 123 returns 0.

It's all a matter of implementation.

At the co-processor level, there appears to be a 7 in the 16th place.
Maybe Excel is doing something similar?

Binomial[9., 3.]//FullForm
84.00000000000007`
...

Note that in Mathematica the result depends on the argument data types.

Binomial[9,3]//FullForn
84

So, it looks like if we dig deep into the math co-processor, some values
will test Zero, and others will not.
...

It's all a question of implementation. The algorithm used to calculate
general binomial coefficients may not return integer results, but
there's NOTHING to stop the implementor adding a lowest order bit and
truncating the result to an integer.

Note that in Mathematica, Binomial[9.,3.] is 2^-47 *greater* than 84
while in Excel COMBIN(9,3) is 2^-46 *less* then 84. Also note that
Mathematica's Binomial function accepts noninteger arguments, e.g.,
Binomial[9.5,3.] returns 100.937, which is the same result as given by

Exp[LogGamma[10.5]-LogGamma[4.]-LogGamma[7.5]]

Note also that after messing around for a while in Mathematica (playing
with N[..] calls), it now returns 84. as the result for
Binomial[9.,3.]//FullForm. Looks like Mathematica also has a fudge
factor for double precision evaluation.

I'll repeat: it's all a matter of implementation, and Excel's is
suboptimal.