Gamma Function by Stieltjes Continued Fraction
|
09-02-2015, 10:53 AM
(This post was last modified: 09-02-2015 08:58 PM by Dieter.)
Post: #2
|
|||
|
|||
RE: Gamma Function by Stieltjes Continued Fraction
(09-01-2015 10:31 PM)lcwright1964 Wrote: In high precision environments where adequate guard digits are not an issue (e.g., quadruple precision on Free42 Decimal), the approximation gives 10 digits easily (a minimum of about 10.4 exact decimal digits [edd] to be precise), and usually 11 or more across the argument range 0 to 70. The error decreases as x increases. So the largest errors occur with small x, like 0...7 – 12 where they may cause the 10th digit to round incorrectly. For x>13 the relative error drops below 1E–11 so that the 10-digit result shoud be within ±0,6 ULP (like the built-in transcendental functions). (09-01-2015 10:31 PM)lcwright1964 Wrote: I am keen on suggestions to save steps, because I would like to be able to fit the routine into the 49 steps of the HP33C/E or the HP25. Here is a first idea. The two multiplications after step 40 obviously avoid overflow for large arguments. But they can be coded more straightforward: Instead of... Code: ... ...what about this one: Code: ... Also on other calculators the final 0 X<>M may be replaced by a simple RCL M (resp. RCL 0), since the zero only clears the 41's M-register to avoid leaving strange characters in Alpha. And finally here is another possible improvement in terms of accuracy. The crucial point of the Stieltjes method is the exponential of a number close to x (cf. step 33). If x exceeds 10, the argument of the e^x function is >10 so that 1 ULP equals 1 E–8, which in turn means that the result of e^x has a potential relative error of 1 E–8. So at this point we may lose up to two digits! A possible solution is... Code: ... ...this method, i.e. instead of e^(a–x) evaluate e^a / e^x. Try x=30, 50 or 70 with the original code and compare with the result of the proposed method: In both cases the latter yields one more valid digit, here it is even dead on in two out or three cases. You may even tweak the results slightly by replacing the multiplication by sqrt(2 Pi) with a division by sqrt(0,5/Pi) – this constant rounds better to 10 digits. ;-) The only drawback is that for integer arguments below 10 the results are off in the last digit while the original code happens to round nicely to the exact integer solution. But then try x=10, 11, 12, 13, 14... Although I haven't done any comprehensive tests, it looks like the proposed changes may yield results with an error within 10 ULP or 1 unit in the 9th digit, even on a 10-digit calculator like the 41 or 67/97. But be sure to do your own tests. Addendum: here are some results from GMST and a modified version. Code: x GMST ULP modified ULP exact Dieter |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)