Dear all, I was comparing the accuracy of FFT and two exact formulas for the FFT of a complex exponential and I was first surprised by a relative accuracy of only 10^-13 for N = 4096, but on second thought it may be related to arithmetic errors due to about N*log2(N) sums and products. But I was much more surprised to detect similar errors between different exact formulas. These formulas involve a few instances of exponentials so I conjectured that the problem may be related to the exponential accuracy. When trying to find some information about accuracy in the documentation I found none. The only mention in the elementary function set to accuracy appears in log1p(), a strange function equal to log(1+x), which is seemingly included to fix some accuracy problem of the natural logarithm very close to 1. Intuition suggests that near 1 the Taylor approximation for log(1+x) should work very well. I guess that is what log1p() does, so I wonder why a function such as log1p is really necessary. It seems more reasonable to internally detect the favorable situation and switch the algorithm to get the maximum attainable accuracy. So if one needs an accurate log(1+x) function, one would just type log(1+x)! But regardless of this discusion, I think it would very useful some hints about accuracy in the help pages of elementary and other functions. For instance, with format(25) --> exp(10) ans = 22026.465794806717894971 while the Windows calculator (which is generally accurate to the last shown digit) yields 22026.465794806716516957900645284 The underlined digits are the least significant ones common to both solutions. Scilab shows up to 25 digits, but only the first 16 of them are accurate. Regards, Federico Miyara _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Hi Fredrico, See the discussion @ here is a relevant excerpt: The Taylor series for log(x) is usually done about x = 1 . So every term will have x - 1 . If you're trying to compute log(x + 1) for a very small x , a direct call as log(x + 1) will result in x + 1 - 1 which will drop all the low-order bits of x - thereby losing precision if x is really small. A built-in log(x+1) can then elide this x + 1 - 1 step and preserve the full precision
_______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Stéphane, Thanks. I think I get the idea: log(1+x) allows values much closer to 1 than possible with log(x) because x could fall down way below %eps, since the full folating point range for small values would be available (about 1e-323). But then the same would be true for any function that happens to be 0 at some point, such as cos(x) at %pi/2, or besselj(x) at any of its zeros. Besides, for any value for which log1p() is relevant (in the sense that it would differ from an optimized log(x) that is accurate up to 1 + %eps or so) probably log1p(x) wouldn't differ from x, since the next digit, corresponding to the x^2 Taylor term cannot fit in the mantissa of a double different from x. For instance (as per Wolfram Alpha site --truncated), log(1 + 1e-16) = 9.99999999999999950000000000000003333333333333333083333333333333353333333333333331... × 10^-17 Attempting to represent this with double, it yields 0.0000000000000001 No difference from 1e-16 since the next different digit would produce a difference below %eps. log1p() would make sense in case the result could be given with extended precision Regards, Federico Miyara On 03/05/2020 05:41, Stéphane Mottelet
wrote:
_______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Free forum by Nabble | Edit this page |