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:
Hi Fredrico,
See the discussion @
https://stackoverflow.com/questions/52736011/instruction-fyl2xp1
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
Le 3 mai 2020 à 08:52, Federico Miyara <[email protected]> a
écrit :
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 informationabout
accuracyin 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 wouldjusttype 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.4657948067_1_7894971
while the Windows calculator (which is generally accurate to the last
shown digit) yields
22026.4657948067_1_6516957900645284
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
[email protected]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
