[Rd] Inaccurate complex arithmetic of R (Matlab is accurate)
Dear All,
Hans Borchers and I have been trying to compute exact derivatives in R using
the idea of complex-step derivatives that Hans has proposed. This is a really,
really cool idea. It gives exact derivatives with only a minimal effort
(same as that involved in computing first-order forward-difference derivative).
Unfortunately, we cannot implement this in R as the complex arithmetic in R
appears to be inaccurate.
Here is an example:
#-- Classical Rosenbrock function in n variables
rosen - function(x) {
n - length(x)
x1 - x[2:n]
x2 - x[1:(n-1)]
sum(100*(x1-x2^2)^2 + (1-x2)^2)
}
x0 - c(0.0094, 0.7146, 0.2179, 0.6883, 0.5757, 0.9549, 0.7136, 0.0849, 0.4147,
0.4540)
h - c(1.e-15*1i, 0, 0, 0, 0, 0, 0, 0, 0, 0)
xh - x0 + h
rx - rosen(xh)
Re(rx)
Im (rx)
# rx = 190.3079796814885 - 12.13915588266717e-15 i # incorrect imaginary part
in R
However, the imaginary part of the above answer is inaccurate. The correct
imaginary part (from Matlab) is:
190.3079796814886 - 4.6677637664e-15 i # correct imaginary part from Matlab
This inaccuracy is serious enough to affect the acuracy of the compex-step
gradient drastically.
Hans and I were wondering if there is a way to obtain accurate small
imaginary part for complex arithmetic.
I am using Windows XP operating system.
Thanks for taking a look at this.
Best regards,
Ravi.
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology
School of Medicine
Johns Hopkins University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
Full_Name: jan hattendorf
Version: 2.9.0
OS: XP
Submission from: (NULL) (213.3.108.185)
I get an incorrect result for
(41/10-1/10)%%1
[1] 1
The error did not occur with other numbers than 41 (1, 11, 21, 31, 51, ...)
test - rep(NA, 1000)
for(i in 1:1000){
test[i] - i/10-1/10
}
test[test%%1==0]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
jan.hattend...@unibas.ch wrote:
Full_Name: jan hattendorf
Version: 2.9.0
OS: XP
Submission from: (NULL) (213.3.108.185)
I get an incorrect result for
(41/10-1/10)%%1
[1] 1
The error did not occur with other numbers than 41 (1, 11, 21, 31, 51, ...)
test - rep(NA, 1000)
for(i in 1:1000){
test[i] - i/10-1/10
}
test[test%%1==0]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
FAQ 7.31
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
Not a bug, just a FAQ (7.31).
http://CRAN.R-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
On Sat, 1 Aug 2009, jan.hattend...@unibas.ch wrote:
Full_Name: jan hattendorf
Version: 2.9.0
OS: XP
Submission from: (NULL) (213.3.108.185)
I get an incorrect result for
(41/10-1/10)%%1
[1] 1
The error did not occur with other numbers than 41 (1, 11, 21, 31, 51, ...)
test - rep(NA, 1000)
for(i in 1:1000){
test[i] - i/10-1/10
}
test[test%%1==0]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
This is not a bug. It is a case of R FAQ 7.34:
http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-the
se-numbers-are-equal_003f
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature
and Forest
Cel biometrie, methodologie en kwaliteitszorg / Section biometrics,
methodology and quality assurance
Gaverstraat 4
9500 Geraardsbergen
Belgium
tel. + 32 54/436 185
thierry.onkel...@inbo.be
www.inbo.be
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to
say what the experiment died of.
~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data.
~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of
data.
~ John Tukey
-Oorspronkelijk bericht-
Van: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] Namens jan.hattend...@unibas.ch
Verzonden: zaterdag 1 augustus 2009 22:05
Aan: r-de...@stat.math.ethz.ch
CC: r-b...@r-project.org
Onderwerp: [Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
Full_Name: jan hattendorf
Version: 2.9.0
OS: XP
Submission from: (NULL) (213.3.108.185)
I get an incorrect result for
(41/10-1/10)%%1
[1] 1
The error did not occur with other numbers than 41 (1, 11, 21, 31, 51,
...)
test - rep(NA, 1000)
for(i in 1:1000){
test[i] - i/10-1/10
}
test[test%%1==0]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer
en binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is
door een geldig ondertekend document. The views expressed in this message
and any annex are purely those of the writer and may not be regarded as stating
an official position of INBO, as long as the message is not confirmed by a duly
signed document.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
Good morning Jan,
Could this be covered off by the following?
http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
Kind regards,
Sean
On Sat, Aug 1, 2009 at 9:05 PM, jan.hattend...@unibas.ch wrote:
Full_Name: jan hattendorf
Version: 2.9.0
OS: XP
Submission from: (NULL) (213.3.108.185)
I get an incorrect result for
(41/10-1/10)%%1
[1] 1
The error did not occur with other numbers than 41 (1, 11, 21, 31, 51, ...)
test - rep(NA, 1000)
for(i in 1:1000){
test[i] - i/10-1/10
}
test[test%%1==0]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate complex arithmetic of R (Matlab is accurate)
Dear Ravi,
the inaccuracy seems to creep in when powers are calculated. Apparently,
some quite general function is called to calculate the squares, and one
can avoid the error by reformulating the example as follows:
rosen - function(x) {
n - length(x)
x1 - x[2:n]
x2 - x[1:(n-1)]
sum(100*(x1-x2*x2)*(x1-x2*x2) + (1-x2)*(1-x2))
}
x0 - c(0.0094, 0.7146, 0.2179, 0.6883, 0.5757, 0.9549, 0.7136, 0.0849, 0.4147,
0.4540)
h - c(1.e-15*1i, 0, 0, 0, 0, 0, 0, 0, 0, 0)
xh - x0 + h
rx - rosen(xh)
Re(rx)
Im (rx)
I don't know which arithmetics are involved in the application you
mentioned, but writing some auxiliary function for the calculation of
x^n when x is complex and n is (a not too large) integer may solve some
of the numerical issues. A simple version is:
powN - function(x,n) sapply(x,function(x) prod(rep(x,n)))
The corresponding summation in 'rosen' would then read:
sum(100*powN(x1-powN(x2,2),2) + powN(1-x2,2))
HTH,
Martin
Ravi Varadhan wrote:
Dear All,
Hans Borchers and I have been trying to compute exact derivatives in R using the idea of complex-step derivatives that Hans has proposed. This is a really, really cool idea. It gives exact derivatives with only a minimal effort (same as that involved in computing first-order forward-difference derivative).
Unfortunately, we cannot implement this in R as the complex arithmetic in R
appears to be inaccurate.
Here is an example:
#-- Classical Rosenbrock function in n variables
rosen - function(x) {
n - length(x)
x1 - x[2:n]
x2 - x[1:(n-1)]
sum(100*(x1-x2^2)^2 + (1-x2)^2)
}
x0 - c(0.0094, 0.7146, 0.2179, 0.6883, 0.5757, 0.9549, 0.7136, 0.0849, 0.4147,
0.4540)
h - c(1.e-15*1i, 0, 0, 0, 0, 0, 0, 0, 0, 0)
xh - x0 + h
rx - rosen(xh)
Re(rx)
Im (rx)
# rx = 190.3079796814885 - 12.13915588266717e-15 i # incorrect imaginary part
in R
However, the imaginary part of the above answer is inaccurate. The correct
imaginary part (from Matlab) is:
190.3079796814886 - 4.6677637664e-15 i # correct imaginary part from Matlab
This inaccuracy is serious enough to affect the acuracy of the compex-step
gradient drastically.
Hans and I were wondering if there is a way to obtain accurate small imaginary part for complex arithmetic.
I am using Windows XP operating system.
Thanks for taking a look at this.
Best regards,
Ravi.
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology
School of Medicine
Johns Hopkins University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Martin Becker
Statistics and Econometrics
Saarland University
Campus C3 1, Room 206
66123 Saarbruecken
Germany
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect result (41/10-1/10)%%1 (PR#13863)
I get an incorrect result for (41/10-1/10)%%1 [1] 1 Note that due to rounding errors, 41/10-1/10 is formatC(41/10-1/10, digits=20) # [1] 3.9995559 Besides FAQ 7.31, related information may be found also at http://wiki.r-project.org/rwiki/doku.php?id=misc:r_accuracy Petr. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] debug: mtrace(fun, FALSE) doesn't work for me
Hi tmp - function(t=1) t+1 mtrace(tmp) mtrace(tmp) #Re-applying trace... #Error in `[[-`(`*tmp*`, 1, value = list(t + 1)) : # incompatible types (from list to expression) in [[ assignment I think this used to work on my computer. A month ago I upgraded R from r-base (2.9.0-4intrepid0) to 2.9.1-2intrepid. Apparently it would be fixed if unmtrace is changed from body(f) - list(body(f)[[3]]) to body(f) - body(f)[[3]] -- Regards Rune Schjellerup Philosof Ph.d.-studerende, Statistik, IST, SDU Telefon: 6550 3607 E-mail: rphilo...@health.sdu.dk Adresse: J.B. Winsløwsvej 9, 5000 Odense C __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate complex arithmetic of R (Matlab is accurate)
Thanks for pointing out the weak point in this computation. I tried out your
suggestions and they both deliver the correct and accurate result.
But as a general solution this approach is not feasible. We want to provide
complex-step derivatives as a new method for computing exact gradients, for
example in 'numDeriv::grad' as
grad(fun, x, method=complex-step)
and we can not reasonably assume that a user prepares his function specially
for calling this method.
I tried out other numerical math software besides Matlab, that is Octave,
Scilab, Euler and others, and they all return the same correct value up to 15
digits. Should we not expect that R is capable of doing the same?
Hans W. Borchers
Martin Becker martin.becker at mx.uni-saarland.de writes:
Dear Ravi,
the inaccuracy seems to creep in when powers are calculated. Apparently,
some quite general function is called to calculate the squares, and one
can avoid the error by reformulating the example as follows:
rosen - function(x) {
n - length(x)
x1 - x[2:n]
x2 - x[1:(n-1)]
sum(100*(x1-x2*x2)*(x1-x2*x2) + (1-x2)*(1-x2))
}
x0 - c(0.0094, 0.7146, 0.2179, 0.6883, 0.5757, 0.9549, 0.7136, 0.0849,
0.4147, 0.4540)
h - c(1.e-15*1i, 0, 0, 0, 0, 0, 0, 0, 0, 0)
xh - x0 + h
rx - rosen(xh)
Re(rx)
Im (rx)
I don't know which arithmetics are involved in the application you
mentioned, but writing some auxiliary function for the calculation of
x^n when x is complex and n is (a not too large) integer may solve some
of the numerical issues. A simple version is:
powN - function(x,n) sapply(x,function(x) prod(rep(x,n)))
The corresponding summation in 'rosen' would then read:
sum(100*powN(x1-powN(x2,2),2) + powN(1-x2,2))
HTH,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate complex arithmetic of R (Matlab is accurate)
HWB == Hans W Borchers hwborch...@googlemail.com
on Mon, 3 Aug 2009 13:15:11 + (UTC) writes:
HWB Thanks for pointing out the weak point in this
HWB computation. I tried out your suggestions and they both
HWB deliver the correct and accurate result.
HWB But as a general solution this approach is not
HWB feasible. We want to provide complex-step derivatives
HWB as a new method for computing exact gradients, for
HWB example in 'numDeriv::grad' as
HWB grad(fun, x, method=complex-step)
HWB and we can not reasonably assume that a user prepares
HWB his function specially for calling this method.
HWB I tried out other numerical math software besides
HWB Matlab, that is Octave, Scilab, Euler and others, and
HWB they all return the same correct value up to 15
HWB digits. Should we not expect that R is capable of doing
HWB the same?
R's a ^ b on non-Windows typically uses the C library's
'cpow()' when that is provided (HAVE_C99_COMPLEX).
Indeed, this seems to use the general complex power function
which loses a few bits -- unavoidably.
Our Windows-version of complex a ^ b does so as well.
Here's an R version of what (I believe) once was the C library
cpow(); at least I confirm that it has the same slight
inaccuracy [if you are as this very border line case with '1e-15';
use 1e-12 and you have no problems !! ]
Cpow - function(a,b)
{
## Purpose: a ^ b in complex
## Find bug in complex_pow()
## -
## Author: Martin Maechler, Date: 15 Jan 2000, 21:33
a - as.complex(a)
b - as.complex(b)
hypot - function(x,y)Mod(x + 1i*y)
logr - log(hypot(Re(a), Im(a)) );
logi - atan2(Im(a), Re(a));
x - exp( logr * Re(b) - logi * Im(b) );
y - logr * Im(b) + logi * Re(b);
x * complex(re= cos(y), im= sin(y))
}
So, yes we could check for the special case of ^2 and use
multiplication and then for^ n and ... ...
and only otherwise call cpow(x,y) {or our own C-version of
that}.
I'm looking into implenting that now.
Expect to hear more about it within 24 hours.
Martin Maechler, ETH Zurich
HWB Hans W. Borchers
HWB Martin Becker martin.becker at mx.uni-saarland.de
HWB writes:
Dear Ravi,
the inaccuracy seems to creep in when powers are
calculated. Apparently, some quite general function is
called to calculate the squares, and one can avoid the
error by reformulating the example as follows:
rosen - function(x) { n - length(x) x1 - x[2:n] x2 -
x[1:(n-1)] sum(100*(x1-x2*x2)*(x1-x2*x2) + (1-x2)*(1-x2))
}
x0 - c(0.0094, 0.7146, 0.2179, 0.6883, 0.5757, 0.9549,
0.7136, 0.0849,
HWB 0.4147, 0.4540)
h - c(1.e-15*1i, 0, 0, 0, 0, 0, 0, 0, 0, 0) xh - x0 + h
rx - rosen(xh) Re(rx) Im (rx)
I don't know which arithmetics are involved in the
application you mentioned, but writing some auxiliary
function for the calculation of x^n when x is complex and
n is (a not too large) integer may solve some of the
numerical issues. A simple version is:
powN - function(x,n) sapply(x,function(x)
prod(rep(x,n)))
The corresponding summation in 'rosen' would then read:
sum(100*powN(x1-powN(x2,2),2) + powN(1-x2,2))
HTH,
Martin
__
HWB R-devel@r-project.org mailing list
HWB https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
