What to do? Learn to work with large numbers like that. Sorry, but you just do. A common solution is to use logs. Don't compute those large numbers at all, but compute their logs!
For example, consider a factorial.
But the log of that factorial? There are two ways to do this. First, you can just do
The second recognizes that the gamma function, thus gamma(n) is the same as factorial(n-1). And therefore you can compute the log of the factorial using the gammaln function, which computes the natural log of the gamma function.
Essentially, you need to learn how to work with large numbers. Similarly,
But you can easily enough compute the log of that same binomial coefficient as:
binln = @(N,K) gammaln(N+1) - gammaln(K+1) - gammaln(N-K+1);
So is it correct for small arguments? (The warning message here comes from nchoosek, not gammaln.)
[binln(100,40),log(nchoosek(100,40))]
Warning: Result may not be exact. Coefficient has a maximum relative error of 1.2434e-14, corresponding to absolute error 170927519286259.
As you see, they agree. But binln has no problems at all for very much larger arguments, literally as large as you wish.
Anyway, once you have the logs of a pair of large numbers which you know lie in the numerator and denominator of a fraction, subtract them, and only then, if necessary, exponentiate to get the result you need.
Next, a common reason why numbers get big is you are using series approximations, but trying to push the convergence of that series just too far. Sorry, but this is not at all uncommon. People push things too far, without really understanding the numerical issues. For example, the simple Taylor series for say sin(x) is globally convergent in theory. Theory is great, but often useless in practice. In practice, you cannot take enough terms in that series to get convergence for say x = 100 (radians). Just look at the terms in the series. You are raising x to extremely large powers, and if x is large, things get bad long before they ever get good.
taylor(sin(x),'order',22)
You will see massive subtractive cancellation, and simply will not be able to compute the values for that series for large absolute values of x. It would be a complete waste of time to even try that in double precision arithmetic. Instead, you can do things like the use of range reduction methods, where you can now compute a solution for at least reasonable values of x. For example:
SinApprox = @(x) sum((-1).^(N-1).*x.^(2*N-1)./factorial(2*N-1));
[SinApprox(X),SinApprox(Xhat),sin(100)]
ans =
1.0e+00 *
-7.94697857233433e+20 -0.506365641109755 -0.506365641109759
So while I would avoid trying to evaluate SinApprox(100), SinApprox(-0.5310) is quite well behaved. And that was just a simple range reduction trick.
Another idea is to scale your variables. Too often we see people thinking that whatever units they want to work in is ok. In fact of course that is just wrong. Would you really want to measure the distance to the nearest star in millimeters? In nanometers? Of course not! Use the appropriate units so your numbers are well scaled, well behaved. Pick units that make everything near 1 in magnitude, and you will often be happier. So the distances between the planets in the solar sytem are often measured as multiples of the distance from the earth to the sun, thus an astronomical unit. The distances between nearby stars are measured in light years, not feet or meters. But wavelengths of light are often measured in nanometers. The mass of other stars themselves are measured in terms of relative solar masses, so multiples of the mass of our sun. The use of appropriate units often makes any associated computations much better behaved.
In the end, what you need to do is simply just learn the techniques to work with such problems. You may learn some of them in a numerical analysis course, though I doubt most numerical analysis courses really cover this sort of thing explicitly or in any real depth. As well, in almost all cases, going to higher precision arithmetic is not needed, though at times, it can be a fix. I usually call such things a crutch, and say they are best avoided and IMHO only used as a very last resort. (Despite the fact that I have written several versions of high/variable precision arithmetic myself for use by those who really want them.)