[Scilab-users] log and log1p

classic Classic list List threaded Threaded
3 messages Options
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] log and log1p


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
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: log and log1p

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


Le 3 mai 2020 à 08:52, Federico Miyara <[hidden email]> 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 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]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: log and log1p


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 @


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 [hidden email] 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 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]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users