View Question
 Question
 Subject: Logarithms for Mathtalk Category: Science > Math Asked by: mrsneaky-ga List Price: \$10.00 Posted: 19 Feb 2004 23:32 PST Expires: 20 Mar 2004 23:32 PST Question ID: 308728
 ```I was checking to see if I learned anything. What is the largest value that X!<= 2^8,192(X Factorial)? I calculated 966. Am I right? Reference from last question: http://answers.google.com/answers/threadview?id=292562``` Clarification of Question by mrsneaky-ga on 19 Feb 2004 23:33 PST `966!` Request for Question Clarification by mathtalk-ga on 20 Feb 2004 17:29 PST ```Hi, mrsneaky-ga: I'm on it! By the way, did you look at the problem: (x!)^2 = (x+1)! for x > 1, as suggested here: http://answers.google.com/answers/threadview?id=293570 Naturally a noninteger value of x is required, but the Windows calculator (in "scientific" mode) seems to handle these correctly. -- mathtalk-ga```
 Subject: Re: Logarithms for Mathtalk Answered By: mathtalk-ga on 23 Feb 2004 19:44 PST
 ```Hi, MrSneaky-ga: You are correct, the largest integer X such that X! < 2^8192 is 966. To compare 966! and 2^8192 I think it's satisfactory to compare the numerical values of their natural logarithms: ln(966!) = SUM ln(k) FOR k = 1 to 966 ~ 5677.8 ln(2^8192) = ln(2) * 8192 ~ 5678.3 Considering that the binary exponent 8192 is given here (number of bits in a kilobyte), the approximation 966! is actually surprisingly close. Roughly: (966! / 2^8192) ~ 0.65 So when one jumps to 967!, one overshoots 2^8192 be a considerable margin. I did these numbers both with the Windows calculator (and rounded to one decimal of accuracy) and with Gnu Octave, a free open source mathematical modelling environment similar to Matlab. Since there are only 966 terms in the summation, I have little doubt that rounding effects do not affect the result of the comparison. In the earlier problem there were almost two orders of magnitude more terms to add, so I went to some trouble to do the comparision with very limited amounts of numeric calculation. In general adding a series of positive number is one of the most stable calculations, so far as effects of rounding errors are concerned. When the terms of summation are all roughly the same magnitude, the behavior of the rounding errors is a nice application of the "random walk" principle (in one dimension). If A is the average absolute size of a rounding error in a single summand, then the total rounding error in adding up N terms has an expected (average) absolute value of about A times the square root of N (for sufficiently large N). This assumes the individual terms are equally likely to have been rounded up as down, so that there's no "systematic" direction to the rounding errors. Thus, if our individual terms had rounding errors of (say) +/- 0.01, we'd expect the summation of 966 of those terms to have a combined error of something like 31 times that: SQRT(966) = 31.08... Of course if the actual logarithm computations are in double precision, then the rounding errors will be many orders of magnitude smaller than that. But if the computations were done in single precision, it might give one a moment's pause to know that the actual difference in logarithms above is about 0.42. Since ln(966) ~ 6.873... the absolute size of individual rounding errors in (well done) single precision would be roughly 0.000002. So even with "worst case" rounding (systematically to one direction or the other), summing up 966 terms would not introduce significant error in the comparison. Some basic aspects of rounding errors are discussed by Donald Knuth in the 2nd volume of his Art of Computer Programming series. For an excerpt of that material, see here: [Floating point arithmetic errors] http://w3rum.upr.clu.edu/htmldocs/fortran/ch4-6.html regards, mathtalk-ga```
 There are no comments at this time.