Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
P == ProfJCNash profjcn...@gmail.com
on Sat, 4 Jul 2015 21:42:27 -0400 writes:
P n163 - mpfr(163, 500)
P is how I set up the number.
Yes, and you have needed to specify the desired precision.
As author and maintainer of Rmpfr, let me give my summary of this overly
long thread (with many wrong statements before finally RK give
the obvious answer):
1) Rmpfr is about high (or low, for didactical reasons, see Rich
Heiberger's talk at 'useR! 2015') precision __numerical__ computations.
This is what the GNU MPFR library is about, and Rmpfr wants
to be a smart and R-like {e.g., automatic coercions wherever they
make sense} R interface to MPFR.
2) If you use Rmpfr, you as user should decide about the desired accuracy
of your inputs.
I think it would be a very bad idea to redefine 'pi' (in
Rmpfr) to be Const(pi, 120).
R-like also means that in a computation a * b the
properties of a and b determine the result, and hence if a - pi
then we know that pi is a double precision number with 53-bit
mantissa.
p On 15-07-04 05:10 PM, Ravi Varadhan wrote:
What about numeric constants, like `163'?
well, if you _combine_ them with an mpfr() number, they are used
in their precision. An integer like 163 is exact of course; but
pi (another numeric constant) is 53-bit as mentioned above,
*and* sqrt(163) is (R-like) a double precision number
computed by R's internal double precision arithmetic.
My summary:
1. Rmpfr behaves entirely correctly and as documented
(in all the examples given here).
2. The idea of substituting expressions containing pi with
something like Const(pi, 120) is not a good one. (*)
*) One could think of adding a new class, say symbolicNumber
or rather numericExpression which in arithmetic would
try to behave correctly, namely find out what precision all
the other components in the arithmetic have and make sure
all parts of the 'numericExpression' are coerced to
'mpfr' with the correct precision, and only then start
evaluating the arithmetic.
But that *does* look like implementation of
Maple/Mathematica/... in R and that seems silly; rather R
should interface to Free (as in speech) aka open source
symbolic math packages such as Pari, macysma, ..
Martin Maechler
ETH Zurich
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
On 04/07/2015 3:45 AM, David Winsemius wrote:
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net wrote:
It doesn’t appear to me that mpfr was ever designed to handle expressions as
the first argument.
This could be a start. Obviously one would wnat to include code to do other
substitutions probably using the all.vars function to pull out the other
“constants” and ’numeric’ values to make them of equivalent precision. I’m
guessing you want to follow the parse-tree and then testing the numbers for
integer-ness and then replacing by paste0( “mpfr(“, val, “L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Duncan Murdoch
spi - paste0(Const('pi',,prec,”)”)
sexpr - gsub(pi, spi, sexpr)
print( eval(parse(text=sexpr))) }
# Very minimal testing
Pre(pi,120)
1 'mpfr' number of precision 120 bits
[1] 3.1415926535897932384626433832795028847
Pre(exp(pi),120)
1 'mpfr' number of precision 120 bits
[1] 23.140692632779269005729086367948547394
Pre(log(exp(pi)),120)
1 'mpfr' number of precision 120 bits
[1] 3.1415926535897932384626433832795028847
At the moment it still needs to ahve other numbers mpfr-ified to succeed:
Pre(pi-4*atan(1),120)
1 'mpfr' number of precision 120 bits
[1] 1.2246467991473531772315719253130892016e-16
Pre(pi-4*atan(mpfr(1,120)),120)
1 'mpfr' number of precision 120 bits
[1] 0
Best;
David.
—
David
On Jul 3, 2015, at 12:01 PM, Ravi Varadhan ravi.varad...@jhu.edu wrote:
Thank you all. I did think about declaring `pi' as a special constant, but
for some reason didn't actually try it.
Would it be easy to have the mpfr() written such that its argument is
automatically of extended precision? In other words, if I just called:
mpfr(exp(sqrt(163)*pi, 120), then all the constants, 163, pi, are
automatically of 120 bits precision.
Is this easy to do?
Best,
Ravi
From: David Winsemius dwinsem...@comcast.net
Sent: Friday, July 3, 2015 2:06 PM
To: John Nash
Cc: r-help; Ravi Varadhan
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote:
Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra
traffic.
In case anyone gets a duplicate, R-help bounced my msg from non-member
(I changed server, but not email yesterday,
so possibly something changed enough). Trying again.
JN
I got the Wolfram answer as follows:
library(Rmpfr)
n163 - mpfr(163, 500)
n163
pi500 - mpfr(pi, 500)
pi500
pitan - mpfr(4, 500)*atan(mpfr(1,500))
pitan
pitan-pi500
r500 - exp(sqrt(n163)*pitan)
r500
check - 262537412640768743.25007259719818568887935385...
savehistory(jnramanujan.R)
Note that I used 4*atan(1) to get pi.
RK got it right by following the example in the help page for mpfr:
Const(pi, 120)
The R `pi` constant is not recognized by mpfr as being anything other than
another double .
There are four special values that mpfr recognizes.
—
Best;
David
It seems that may be important,
rather than converting.
JN
On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote:
Message: 40
Date: Thu, 2 Jul 2015 22:38:45 +
From: Ravi Varadhan ravi.varad...@jhu.edu
To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh
aps...@yahoo.com
Cc: r-help r-help@r-project.org
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
Message-ID:
14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu
Content-Type: text/plain; charset=utf-8
Hi Rich,
The Wolfram answer is correct.
http://mathworld.wolfram.com/RamanujanConstant.html
There is no code for Wolfram alpha. You just go to their web engine and
plug in the expression and it will give you the answer.
http://www.wolframalpha.com/
I am not sure that the precedence matters in Rmpfr. Even if it does, the
answer you get is still wrong as you showed.
Thanks,
Ravi
-Original Message-
From: Richard M. Heiberger [mailto:r...@temple.edu]
Sent: Thursday, July 02, 2015 6:30 PM
To: Aditya Singh
Cc: Ravi Varadhan; r-help
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
There is a precedence error in your R attempt. You need to convert
163 to 120 bits first, before taking
its square root.
exp(sqrt(mpfr(163, 120)) * mpfr(pi
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
On 04/07/2015 8:21 AM, David Winsemius wrote:
On Jul 3, 2015, at 11:05 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 04/07/2015 3:45 AM, David Winsemius wrote:
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net wrote:
It doesn’t appear to me that mpfr was ever designed to handle expressions
as the first argument.
This could be a start. Obviously one would wnat to include code to do other
substitutions probably using the all.vars function to pull out the other
“constants” and ’numeric’ values to make them of equivalent precision. I’m
guessing you want to follow the parse-tree and then testing the numbers for
integer-ness and then replacing by paste0( “mpfr(“, val, “L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Really? I did try. I was fairly sure that someone could do better but I
don’t see an open path along the lines you suggest. I’m pretty sure I tried
`substitute(expr, list(pi= pi))` when `expr` had been the formal argument and
got disappointed because there is no `pi` in the expression `expr`. I
_thought_ the problem was that `substitute` does not evaluate its first
argument, but I do admit to be pretty much of a klutz with this sort of
programming. I don’t think you need to have mpfr installed in order to
demonstrate this.
The substitute() function really does two different things.
substitute(expr) (with no second argument) grabs the underlying
expression out of a promise. substitute(expr, list(pi = pi)) tries to
make the substitution in the expression expr, so it doesn't see pi.
This should work:
do.call(substitute, list(expr = substitute(expr), env=list(pi =
Const(pi, 120
(but I can't evaluate the Const function to test it).
This works:
do.call(substitute, list(expr = substitute(expr), env = list(pi =
quote(Const(pi, 120)
because it never evaluates the Const function, it just returns some code
that you could modify more if you liked.
Duncan Murdoch
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
On Jul 3, 2015, at 11:05 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 04/07/2015 3:45 AM, David Winsemius wrote:
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net wrote:
It doesn’t appear to me that mpfr was ever designed to handle expressions
as the first argument.
This could be a start. Obviously one would wnat to include code to do other
substitutions probably using the all.vars function to pull out the other
“constants” and ’numeric’ values to make them of equivalent precision. I’m
guessing you want to follow the parse-tree and then testing the numbers for
integer-ness and then replacing by paste0( “mpfr(“, val, “L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Really? I did try. I was fairly sure that someone could do better but I don’t
see an open path along the lines you suggest. I’m pretty sure I tried
`substitute(expr, list(pi= pi))` when `expr` had been the formal argument and
got disappointed because there is no `pi` in the expression `expr`. I _thought_
the problem was that `substitute` does not evaluate its first argument, but I
do admit to be pretty much of a klutz with this sort of programming. I don’t
think you need to have mpfr installed in order to demonstrate this.
testf - function(expr) new - substitute(expr, list(pi = 3.121450))
sth-testf(exp(pi))
sth
#expr
—
David.
Duncan Murdoch
spi - paste0(Const('pi',,prec,”)”)
sexpr - gsub(pi, spi, sexpr)
print( eval(parse(text=sexpr))) }
# Very minimal testing
Pre(pi,120)
1 'mpfr' number of precision 120 bits
[1] 3.1415926535897932384626433832795028847
Pre(exp(pi),120)
1 'mpfr' number of precision 120 bits
[1] 23.140692632779269005729086367948547394
Pre(log(exp(pi)),120)
1 'mpfr' number of precision 120 bits
[1] 3.1415926535897932384626433832795028847
At the moment it still needs to ahve other numbers mpfr-ified to succeed:
Pre(pi-4*atan(1),120)
1 'mpfr' number of precision 120 bits
[1] 1.2246467991473531772315719253130892016e-16
Pre(pi-4*atan(mpfr(1,120)),120)
1 'mpfr' number of precision 120 bits
[1] 0
Best;
David.
—
David
On Jul 3, 2015, at 12:01 PM, Ravi Varadhan ravi.varad...@jhu.edu wrote:
Thank you all. I did think about declaring `pi' as a special constant,
but for some reason didn't actually try it.
Would it be easy to have the mpfr() written such that its argument is
automatically of extended precision? In other words, if I just called:
mpfr(exp(sqrt(163)*pi, 120), then all the constants, 163, pi, are
automatically of 120 bits precision.
Is this easy to do?
Best,
Ravi
From: David Winsemius dwinsem...@comcast.net
Sent: Friday, July 3, 2015 2:06 PM
To: John Nash
Cc: r-help; Ravi Varadhan
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote:
Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra
traffic.
In case anyone gets a duplicate, R-help bounced my msg from non-member
(I changed server, but not email yesterday,
so possibly something changed enough). Trying again.
JN
I got the Wolfram answer as follows:
library(Rmpfr)
n163 - mpfr(163, 500)
n163
pi500 - mpfr(pi, 500)
pi500
pitan - mpfr(4, 500)*atan(mpfr(1,500))
pitan
pitan-pi500
r500 - exp(sqrt(n163)*pitan)
r500
check - 262537412640768743.25007259719818568887935385...
savehistory(jnramanujan.R)
Note that I used 4*atan(1) to get pi.
RK got it right by following the example in the help page for mpfr:
Const(pi, 120)
The R `pi` constant is not recognized by mpfr as being anything other than
another double .
There are four special values that mpfr recognizes.
—
Best;
David
It seems that may be important,
rather than converting.
JN
On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote:
Message: 40
Date: Thu, 2 Jul 2015 22:38:45 +
From: Ravi Varadhan ravi.varad...@jhu.edu
To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh
aps...@yahoo.com
Cc: r-help r-help@r-project.org
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
Message-ID:
14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu
Content-Type: text/plain; charset=utf-8
Hi Rich,
The Wolfram answer is correct.
http
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
It doesn’t appear to me that mpfr was ever designed to handle expressions
as the first argument.
This could be a start. Obviously one would wnat to include code to do other
substitutions probably using the all.vars function to pull out the other
“constants” and ’numeric’ values to make them of equivalent precision. I’m
guessing you want to follow the parse-tree and then testing the numbers for
integer-ness and then replacing by paste0( “mpfr(“, val, “L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Really? I did try. I was fairly sure that someone could do better but I
don’t see an open path along the lines you suggest. I’m pretty sure I tried
`substitute(expr, list(pi= pi))` when `expr` had been the formal argument and
got disappointed because there is no `pi` in the expression `expr`. I
_thought_ the problem was that `substitute` does not evaluate its first
argument, but I do admit to be pretty much of a klutz with this sort of
programming. I don’t think you need to have mpfr installed in order to
demonstrate this.
You might want to read http://adv-r.had.co.nz/Expressions.html - it's
my best attempt at explaining how to modify call trees in R.
Hadley
--
http://had.co.nz/
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
On Jul 4, 2015, at 12:20 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 04/07/2015 8:21 AM, David Winsemius wrote:
On Jul 3, 2015, at 11:05 PM, Duncan Murdoch murdoch.dun...@gmail.com
wrote:
On 04/07/2015 3:45 AM, David Winsemius wrote:
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net
wrote:
It doesn’t appear to me that mpfr was ever designed to handle expressions
as the first argument.
This could be a start. Obviously one would wnat to include code to do
other substitutions probably using the all.vars function to pull out the
other “constants” and ’numeric’ values to make them of equivalent
precision. I’m guessing you want to follow the parse-tree and then testing
the numbers for integer-ness and then replacing by paste0( “mpfr(“, val,
“L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Really? I did try. I was fairly sure that someone could do better but I
don’t see an open path along the lines you suggest. I’m pretty sure I tried
`substitute(expr, list(pi= pi))` when `expr` had been the formal argument
and got disappointed because there is no `pi` in the expression `expr`. I
_thought_ the problem was that `substitute` does not evaluate its first
argument, but I do admit to be pretty much of a klutz with this sort of
programming. I don’t think you need to have mpfr installed in order to
demonstrate this.
The substitute() function really does two different things.
substitute(expr) (with no second argument) grabs the underlying
expression out of a promise. substitute(expr, list(pi = pi)) tries to
make the substitution in the expression expr, so it doesn't see pi”.
Thank you. That was really helpful. I hope it “sticks” to sufficiently durable
set of neurons.
This should work:
do.call(substitute, list(expr = substitute(expr), env=list(pi =
Const(pi, 120
(but I can't evaluate the Const function to test it).
The expression `pi` as the argument to Const only needed to be character()-ized
and then evaluation on that result succeeded:
library(mpfr)
# Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const(pi, prec }
Pre(exp(pi),120)
Error in Const(pi, prec) :
'name' must be one of 'pi', 'gamma', 'catalan', 'log2'
Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const('pi', prec }
Pre(exp(pi),120)
exp(list(S4 object of class mpfr1))
eval( Pre(exp(pi),120) )
1 'mpfr' number of precision 120 bits
[1] 23.140692632779269005729086367948547394
So the next step for delivering Ravi’s request would be to add the rest of the
‘Const’ options:
Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const('pi', prec),
catalan=Const('catalan', prec),
log2=Const('log2', prec),
gamma=Const('gamma', prec }
eval(Pre(exp(gamma)))
Error in stopifnot(is.numeric(prec)) :
argument prec is missing, with no default
eval(Pre(exp(gamma), 120))
1 'mpfr' number of precision 120 bits
[1] 1.781072417990197985236504103107179549
This works:
do.call(substitute, list(expr = substitute(expr), env = list(pi =
quote(Const(pi, 120)
because it never evaluates the Const function, it just returns some code
that you could modify more if you liked.
Duncan Murdoch
David Winsemius, MD
Alameda, CA, USA
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
You can do that with bc if you pass the entire expression to bc(...) in quotes but in that case you will have to use bc notation, not R notation so, for example, exp is e and atan is a. library(bc) bc(e(sqrt(163)*4*a(1))) [1] 262537412640768743.2500725971981856888793538563373369908627075374103782106479101186073116295306145602054347 On Fri, Jul 3, 2015 at 3:01 PM, Ravi Varadhan ravi.varad...@jhu.edu wrote: Thank you all. I did think about declaring `pi' as a special constant, but for some reason didn't actually try it. Would it be easy to have the mpfr() written such that its argument is automatically of extended precision? In other words, if I just called: mpfr(exp(sqrt(163)*pi, 120), then all the constants, 163, pi, are automatically of 120 bits precision. Is this easy to do? Best, Ravi From: David Winsemius dwinsem...@comcast.net Sent: Friday, July 3, 2015 2:06 PM To: John Nash Cc: r-help; Ravi Varadhan Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote: Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra traffic. In case anyone gets a duplicate, R-help bounced my msg from non-member (I changed server, but not email yesterday, so possibly something changed enough). Trying again. JN I got the Wolfram answer as follows: library(Rmpfr) n163 - mpfr(163, 500) n163 pi500 - mpfr(pi, 500) pi500 pitan - mpfr(4, 500)*atan(mpfr(1,500)) pitan pitan-pi500 r500 - exp(sqrt(n163)*pitan) r500 check - 262537412640768743.25007259719818568887935385... savehistory(jnramanujan.R) Note that I used 4*atan(1) to get pi. RK got it right by following the example in the help page for mpfr: Const(pi, 120) The R `pi` constant is not recognized by mpfr as being anything other than another double . There are four special values that mpfr recognizes. — Best; David It seems that may be important, rather than converting. JN On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote: Message: 40 Date: Thu, 2 Jul 2015 22:38:45 + From: Ravi Varadhan ravi.varad...@jhu.edu To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh aps...@yahoo.com Cc: r-help r-help@r-project.org Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R Message-ID: 14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu Content-Type: text/plain; charset=utf-8 Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
n163 - mpfr(163, 500)
is how I set up the number.
JN
On 15-07-04 05:10 PM, Ravi Varadhan wrote:
What about numeric constants, like `163'?
eval(Pre(exp(sqrt(163)*pi), 120))does not work.
Thanks,
Ravi
From: David Winsemius dwinsem...@comcast.net
Sent: Saturday, July 4, 2015 1:12 PM
To: Duncan Murdoch
Cc: r-help; John Nash; Ravi Varadhan
Subject: Re: [R] : Ramanujan and the accuracy of floating point computations
- using Rmpfr in R
On Jul 4, 2015, at 12:20 AM, Duncan Murdoch murdoch.dun...@gmail.com
wrote:
On 04/07/2015 8:21 AM, David Winsemius wrote:
On Jul 3, 2015, at 11:05 PM, Duncan Murdoch murdoch.dun...@gmail.com
wrote:
On 04/07/2015 3:45 AM, David Winsemius wrote:
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net
wrote:
It doesn’t appear to me that mpfr was ever designed to handle
expressions as the first argument.
This could be a start. Obviously one would wnat to include code to do
other substitutions probably using the all.vars function to pull out the
other “constants” and ’numeric’ values to make them of equivalent
precision. I’m guessing you want to follow the parse-tree and then
testing the numbers for integer-ness and then replacing by paste0(
“mpfr(“, val, “L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Really? I did try. I was fairly sure that someone could do better but I
don’t see an open path along the lines you suggest. I’m pretty sure I
tried `substitute(expr, list(pi= pi))` when `expr` had been the formal
argument and got disappointed because there is no `pi` in the expression
`expr`. I _thought_ the problem was that `substitute` does not evaluate
its first argument, but I do admit to be pretty much of a klutz with this
sort of programming. I don’t think you need to have mpfr installed in
order to demonstrate this.
The substitute() function really does two different things.
substitute(expr) (with no second argument) grabs the underlying
expression out of a promise. substitute(expr, list(pi = pi)) tries to
make the substitution in the expression expr, so it doesn't see pi”.
Thank you. That was really helpful. I hope it “sticks” to sufficiently
durable set of neurons.
This should work:
do.call(substitute, list(expr = substitute(expr), env=list(pi =
Const(pi, 120
(but I can't evaluate the Const function to test it).
The expression `pi` as the argument to Const only needed to be
character()-ized and then evaluation on that result succeeded:
library(mpfr)
# Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const(pi,
prec }
Pre(exp(pi),120)
Error in Const(pi, prec) :
'name' must be one of 'pi', 'gamma', 'catalan', 'log2'
Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const('pi', prec
}
Pre(exp(pi),120)
exp(list(S4 object of class mpfr1))
eval( Pre(exp(pi),120) )
1 'mpfr' number of precision 120 bits
[1] 23.140692632779269005729086367948547394
So the next step for delivering Ravi’s request would be to add the rest of
the ‘Const’ options:
Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const('pi', prec),
catalan=Const('catalan', prec),
log2=Const('log2', prec),
gamma=Const('gamma', prec }
eval(Pre(exp(gamma)))
Error in stopifnot(is.numeric(prec)) :
argument prec is missing, with no default
eval(Pre(exp(gamma), 120))
1 'mpfr' number of precision 120 bits
[1] 1.781072417990197985236504103107179549
This works:
do.call(substitute, list(expr = substitute(expr), env = list(pi =
quote(Const(pi, 120)
because it never evaluates the Const function, it just returns some code
that you could modify more if you liked.
Duncan Murdoch
David Winsemius, MD
Alameda, CA, USA
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
What about numeric constants, like `163'?
eval(Pre(exp(sqrt(163)*pi), 120))does not work.
Thanks,
Ravi
From: David Winsemius dwinsem...@comcast.net
Sent: Saturday, July 4, 2015 1:12 PM
To: Duncan Murdoch
Cc: r-help; John Nash; Ravi Varadhan
Subject: Re: [R] : Ramanujan and the accuracy of floating point computations -
using Rmpfr in R
On Jul 4, 2015, at 12:20 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 04/07/2015 8:21 AM, David Winsemius wrote:
On Jul 3, 2015, at 11:05 PM, Duncan Murdoch murdoch.dun...@gmail.com
wrote:
On 04/07/2015 3:45 AM, David Winsemius wrote:
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net
wrote:
It doesn’t appear to me that mpfr was ever designed to handle expressions
as the first argument.
This could be a start. Obviously one would wnat to include code to do
other substitutions probably using the all.vars function to pull out the
other “constants” and ’numeric’ values to make them of equivalent
precision. I’m guessing you want to follow the parse-tree and then testing
the numbers for integer-ness and then replacing by paste0( “mpfr(“, val,
“L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
Why deparse? That's almost never a good idea. I can't try your code (I
don't have mpfr available), but it would be much better to modify the
expression than the text representation of it. For example, I think
your code would modify strings containing pi, or variables with those
letters in them, etc. If you used substitute(expr) without the
deparse(), you could replace the symbol pi with the call to the Const
function, and be more robust.
Really? I did try. I was fairly sure that someone could do better but I
don’t see an open path along the lines you suggest. I’m pretty sure I tried
`substitute(expr, list(pi= pi))` when `expr` had been the formal argument
and got disappointed because there is no `pi` in the expression `expr`. I
_thought_ the problem was that `substitute` does not evaluate its first
argument, but I do admit to be pretty much of a klutz with this sort of
programming. I don’t think you need to have mpfr installed in order to
demonstrate this.
The substitute() function really does two different things.
substitute(expr) (with no second argument) grabs the underlying
expression out of a promise. substitute(expr, list(pi = pi)) tries to
make the substitution in the expression expr, so it doesn't see pi”.
Thank you. That was really helpful. I hope it “sticks” to sufficiently durable
set of neurons.
This should work:
do.call(substitute, list(expr = substitute(expr), env=list(pi =
Const(pi, 120
(but I can't evaluate the Const function to test it).
The expression `pi` as the argument to Const only needed to be character()-ized
and then evaluation on that result succeeded:
library(mpfr)
# Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const(pi, prec }
Pre(exp(pi),120)
Error in Const(pi, prec) :
'name' must be one of 'pi', 'gamma', 'catalan', 'log2'
Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const('pi', prec }
Pre(exp(pi),120)
exp(list(S4 object of class mpfr1))
eval( Pre(exp(pi),120) )
1 'mpfr' number of precision 120 bits
[1] 23.140692632779269005729086367948547394
So the next step for delivering Ravi’s request would be to add the rest of the
‘Const’ options:
Pre - function(expr, prec){ do.call(substitute,
list(expr = substitute(expr),
env=list(pi = Const('pi', prec),
catalan=Const('catalan', prec),
log2=Const('log2', prec),
gamma=Const('gamma', prec }
eval(Pre(exp(gamma)))
Error in stopifnot(is.numeric(prec)) :
argument prec is missing, with no default
eval(Pre(exp(gamma), 120))
1 'mpfr' number of precision 120 bits
[1] 1.781072417990197985236504103107179549
This works:
do.call(substitute, list(expr = substitute(expr), env = list(pi =
quote(Const(pi, 120)
because it never evaluates the Const function, it just returns some code
that you could modify more if you liked.
Duncan Murdoch
David Winsemius, MD
Alameda, CA, USA
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra traffic. In case anyone gets a duplicate, R-help bounced my msg from non-member (I changed server, but not email yesterday, so possibly something changed enough). Trying again. JN I got the Wolfram answer as follows: library(Rmpfr) n163 - mpfr(163, 500) n163 pi500 - mpfr(pi, 500) pi500 pitan - mpfr(4, 500)*atan(mpfr(1,500)) pitan pitan-pi500 r500 - exp(sqrt(n163)*pitan) r500 check - 262537412640768743.25007259719818568887935385... savehistory(jnramanujan.R) Note that I used 4*atan(1) to get pi. It seems that may be important, rather than converting. JN On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote: Message: 40 Date: Thu, 2 Jul 2015 22:38:45 + From: Ravi Varadhan ravi.varad...@jhu.edu To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh aps...@yahoo.com Cc: r-help r-help@r-project.org Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R Message-ID: 14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu Content-Type: text/plain; charset=utf-8 Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. -- __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Also when I try the following with Rmpfr, it works jut fine. exp(sqrt(mpfr(163, 120)) * Const(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768743.25007601 and exp(sqrt(mpfr(163, 400)) * Const(pi, 400)) 1 'mpfr' number of precision 400 bits [1] 262537412640768743.25007259719818568887935385633733699086270 753741037821064791011860731295118134618606450419548 Which compares very nicely with the following: In[10]:= N[Exp[Sqrt[163] Pi], 125] Out[10]= 2.6253741264076874325007259719818568887935385633733699086270 753741037821064791011860731295118134618606450419308389*10^17 In the multiprecision business, you can never be too certain that you are using the right precision throughout your calculations. Nordlund, Dan (DSHS/RDA NordlDJ at dshs.wa.gov writes: Ravi, Take a look at the following link. https://code.google.com/p/r-bc/ I followed the instructions to get a Windows version of the 'nix utility program , bc (a high precision calculator), and the source for an R to bc interface. After installing them, I executed exp(sqrt(bc(163))*4*atan(bc(1))) in R and got this result 262537412640768743.2500725971981856888793538563373369908627 075374103782106479101186073116295306145602054347 I don't know if this is helpful, but ... Dan Daniel Nordlund, PhD Research and Data Analysis Division Services Enterprise Support Administration Washington State Department of Social and Health Services __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote: Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra traffic. In case anyone gets a duplicate, R-help bounced my msg from non-member (I changed server, but not email yesterday, so possibly something changed enough). Trying again. JN I got the Wolfram answer as follows: library(Rmpfr) n163 - mpfr(163, 500) n163 pi500 - mpfr(pi, 500) pi500 pitan - mpfr(4, 500)*atan(mpfr(1,500)) pitan pitan-pi500 r500 - exp(sqrt(n163)*pitan) r500 check - 262537412640768743.25007259719818568887935385... savehistory(jnramanujan.R) Note that I used 4*atan(1) to get pi. RK got it right by following the example in the help page for mpfr: Const(pi, 120) The R `pi` constant is not recognized by mpfr as being anything other than another double . There are four special values that mpfr recognizes. — Best; David It seems that may be important, rather than converting. JN On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote: Message: 40 Date: Thu, 2 Jul 2015 22:38:45 + From: Ravi Varadhan ravi.varad...@jhu.edu To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh aps...@yahoo.com Cc: r-help r-help@r-project.org Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R Message-ID: 14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu Content-Type: text/plain; charset=utf-8 Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. -- __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
On Jul 3, 2015, at 5:08 PM, David Winsemius dwinsem...@comcast.net wrote:
It doesn’t appear to me that mpfr was ever designed to handle expressions as
the first argument.
This could be a start. Obviously one would wnat to include code to do other
substitutions probably using the all.vars function to pull out the other
“constants” and ’numeric’ values to make them of equivalent precision. I’m
guessing you want to follow the parse-tree and then testing the numbers for
integer-ness and then replacing by paste0( “mpfr(“, val, “L, “, prec,”)” )
Pre - function(expr, prec){ sexpr - deparse(substitute(expr) )
spi - paste0(Const('pi',,prec,”)”)
sexpr - gsub(pi, spi, sexpr)
print( eval(parse(text=sexpr))) }
# Very minimal testing
Pre(pi,120)
1 'mpfr' number of precision 120 bits
[1] 3.1415926535897932384626433832795028847
Pre(exp(pi),120)
1 'mpfr' number of precision 120 bits
[1] 23.140692632779269005729086367948547394
Pre(log(exp(pi)),120)
1 'mpfr' number of precision 120 bits
[1] 3.1415926535897932384626433832795028847
At the moment it still needs to ahve other numbers mpfr-ified to succeed:
Pre(pi-4*atan(1),120)
1 'mpfr' number of precision 120 bits
[1] 1.2246467991473531772315719253130892016e-16
Pre(pi-4*atan(mpfr(1,120)),120)
1 'mpfr' number of precision 120 bits
[1] 0
Best;
David.
—
David
On Jul 3, 2015, at 12:01 PM, Ravi Varadhan ravi.varad...@jhu.edu wrote:
Thank you all. I did think about declaring `pi' as a special constant, but
for some reason didn't actually try it.
Would it be easy to have the mpfr() written such that its argument is
automatically of extended precision? In other words, if I just called:
mpfr(exp(sqrt(163)*pi, 120), then all the constants, 163, pi, are
automatically of 120 bits precision.
Is this easy to do?
Best,
Ravi
From: David Winsemius dwinsem...@comcast.net
Sent: Friday, July 3, 2015 2:06 PM
To: John Nash
Cc: r-help; Ravi Varadhan
Subject: Re: [R] : Ramanujan and the accuracy of floating point computations
- using Rmpfr in R
On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote:
Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra
traffic.
In case anyone gets a duplicate, R-help bounced my msg from non-member (I
changed server, but not email yesterday,
so possibly something changed enough). Trying again.
JN
I got the Wolfram answer as follows:
library(Rmpfr)
n163 - mpfr(163, 500)
n163
pi500 - mpfr(pi, 500)
pi500
pitan - mpfr(4, 500)*atan(mpfr(1,500))
pitan
pitan-pi500
r500 - exp(sqrt(n163)*pitan)
r500
check - 262537412640768743.25007259719818568887935385...
savehistory(jnramanujan.R)
Note that I used 4*atan(1) to get pi.
RK got it right by following the example in the help page for mpfr:
Const(pi, 120)
The R `pi` constant is not recognized by mpfr as being anything other than
another double .
There are four special values that mpfr recognizes.
—
Best;
David
It seems that may be important,
rather than converting.
JN
On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote:
Message: 40
Date: Thu, 2 Jul 2015 22:38:45 +
From: Ravi Varadhan ravi.varad...@jhu.edu
To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh
aps...@yahoo.com
Cc: r-help r-help@r-project.org
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
Message-ID:
14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu
Content-Type: text/plain; charset=utf-8
Hi Rich,
The Wolfram answer is correct.
http://mathworld.wolfram.com/RamanujanConstant.html
There is no code for Wolfram alpha. You just go to their web engine and
plug in the expression and it will give you the answer.
http://www.wolframalpha.com/
I am not sure that the precedence matters in Rmpfr. Even if it does, the
answer you get is still wrong as you showed.
Thanks,
Ravi
-Original Message-
From: Richard M. Heiberger [mailto:r...@temple.edu]
Sent: Thursday, July 02, 2015 6:30 PM
To: Aditya Singh
Cc: Ravi Varadhan; r-help
Subject: Re: [R] : Ramanujan and the accuracy of floating point
computations - using Rmpfr in R
There is a precedence error in your R attempt. You need to convert
163 to 120 bits first, before taking
its square root.
exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120))
1 'mpfr' number of precision 120 bits
[1] 262537412640768333.51635812597335712954
## just the last four characters to the left of the decimal point.
tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837)
tmp-tmp[2]
baseRWolfram Rmpfr wrongRmpfr
-488 0 -411 -907
You didn't give the Wolfram alpha code you used. There is no way of
verifying the correct value from your email.
Please check that you didn't have a similar precedence error
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Thank you all. I did think about declaring `pi' as a special constant, but for some reason didn't actually try it. Would it be easy to have the mpfr() written such that its argument is automatically of extended precision? In other words, if I just called: mpfr(exp(sqrt(163)*pi, 120), then all the constants, 163, pi, are automatically of 120 bits precision. Is this easy to do? Best, Ravi From: David Winsemius dwinsem...@comcast.net Sent: Friday, July 3, 2015 2:06 PM To: John Nash Cc: r-help; Ravi Varadhan Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote: Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra traffic. In case anyone gets a duplicate, R-help bounced my msg from non-member (I changed server, but not email yesterday, so possibly something changed enough). Trying again. JN I got the Wolfram answer as follows: library(Rmpfr) n163 - mpfr(163, 500) n163 pi500 - mpfr(pi, 500) pi500 pitan - mpfr(4, 500)*atan(mpfr(1,500)) pitan pitan-pi500 r500 - exp(sqrt(n163)*pitan) r500 check - 262537412640768743.25007259719818568887935385... savehistory(jnramanujan.R) Note that I used 4*atan(1) to get pi. RK got it right by following the example in the help page for mpfr: Const(pi, 120) The R `pi` constant is not recognized by mpfr as being anything other than another double . There are four special values that mpfr recognizes. — Best; David It seems that may be important, rather than converting. JN On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote: Message: 40 Date: Thu, 2 Jul 2015 22:38:45 + From: Ravi Varadhan ravi.varad...@jhu.edu To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh aps...@yahoo.com Cc: r-help r-help@r-project.org Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R Message-ID: 14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu Content-Type: text/plain; charset=utf-8 Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
It doesn’t appear to me that mpfr was ever designed to handle expressions as the first argument. — David On Jul 3, 2015, at 12:01 PM, Ravi Varadhan ravi.varad...@jhu.edu wrote: Thank you all. I did think about declaring `pi' as a special constant, but for some reason didn't actually try it. Would it be easy to have the mpfr() written such that its argument is automatically of extended precision? In other words, if I just called: mpfr(exp(sqrt(163)*pi, 120), then all the constants, 163, pi, are automatically of 120 bits precision. Is this easy to do? Best, Ravi From: David Winsemius dwinsem...@comcast.net Sent: Friday, July 3, 2015 2:06 PM To: John Nash Cc: r-help; Ravi Varadhan Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R On Jul 3, 2015, at 8:08 AM, John Nash john.n...@uottawa.ca wrote: Third try -- I unsubscribed and re-subscribed. Sorry to Ravi for extra traffic. In case anyone gets a duplicate, R-help bounced my msg from non-member (I changed server, but not email yesterday, so possibly something changed enough). Trying again. JN I got the Wolfram answer as follows: library(Rmpfr) n163 - mpfr(163, 500) n163 pi500 - mpfr(pi, 500) pi500 pitan - mpfr(4, 500)*atan(mpfr(1,500)) pitan pitan-pi500 r500 - exp(sqrt(n163)*pitan) r500 check - 262537412640768743.25007259719818568887935385... savehistory(jnramanujan.R) Note that I used 4*atan(1) to get pi. RK got it right by following the example in the help page for mpfr: Const(pi, 120) The R `pi` constant is not recognized by mpfr as being anything other than another double . There are four special values that mpfr recognizes. — Best; David It seems that may be important, rather than converting. JN On 15-07-03 06:00 AM, r-help-requ...@r-project.org wrote: Message: 40 Date: Thu, 2 Jul 2015 22:38:45 + From: Ravi Varadhan ravi.varad...@jhu.edu To: 'Richard M. Heiberger' r...@temple.edu, Aditya Singh aps...@yahoo.com Cc: r-help r-help@r-project.org Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R Message-ID: 14ad39aaf6a542849bbf3f62a0c2f...@dom-eb1-2013.win.ad.jhu.edu Content-Type: text/plain; charset=utf-8 Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
But not 120 bits of pi... just 120 bits of the double precision version of pi. --- Jeff NewmillerThe . . Go Live... DCN:jdnew...@dcn.davis.ca.usBasics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- Sent from my phone. Please excuse my brevity. On July 2, 2015 3:51:55 PM PDT, Richard M. Heiberger r...@temple.edu wrote: precedence does matter in this example. the square root was taken of a doubleprecision (53 bit) number. my revision takes the square root of a 120 bit number. sqrt(mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 1.7724538509055159927515191031392484397 mpfr(sqrt(pi), 120) 1 'mpfr' number of precision 120 bits [1] 1.772453850905515881919427556567825377 print(sqrt(pi), digits=20) [1] 1.7724538509055158819 Sent from my iPhone On Jul 3, 2015, at 00:38, Ravi Varadhan ravi.varad...@jhu.edu wrote: Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
precedence does matter in this example. the square root was taken of a doubleprecision (53 bit) number. my revision takes the square root of a 120 bit number. sqrt(mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 1.7724538509055159927515191031392484397 mpfr(sqrt(pi), 120) 1 'mpfr' number of precision 120 bits [1] 1.772453850905515881919427556567825377 print(sqrt(pi), digits=20) [1] 1.7724538509055158819 Sent from my iPhone On Jul 3, 2015, at 00:38, Ravi Varadhan ravi.varad...@jhu.edu wrote: Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Ravi, Take a look at the following link. https://code.google.com/p/r-bc/ I followed the instructions to get a Windows version of the 'nix utility program , bc (a high precision calculator), and the source for an R to bc interface. After installing them, I executed exp(sqrt(bc(163))*4*atan(bc(1))) in R and got this result 262537412640768743.2500725971981856888793538563373369908627075374103782106479101186073116295306145602054347 I don't know if this is helpful, but ... Dan Daniel Nordlund, PhD Research and Data Analysis Division Services Enterprise Support Administration Washington State Department of Social and Health Services -Original Message- From: R-help [mailto:r-help-boun...@r-project.org] On Behalf Of Jeff Newmiller Sent: Thursday, July 02, 2015 4:13 PM To: Richard M. Heiberger; Ravi Varadhan Cc: r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R But not 120 bits of pi... just 120 bits of the double precision version of pi. --- Jeff NewmillerThe . . Go Live... DCN:jdnew...@dcn.davis.ca.usBasics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- Sent from my phone. Please excuse my brevity. On July 2, 2015 3:51:55 PM PDT, Richard M. Heiberger r...@temple.edu wrote: precedence does matter in this example. the square root was taken of a doubleprecision (53 bit) number. my revision takes the square root of a 120 bit number. sqrt(mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 1.7724538509055159927515191031392484397 mpfr(sqrt(pi), 120) 1 'mpfr' number of precision 120 bits [1] 1.772453850905515881919427556567825377 print(sqrt(pi), digits=20) [1] 1.7724538509055158819 Sent from my iPhone On Jul 3, 2015, at 00:38, Ravi Varadhan ravi.varad...@jhu.edu wrote: Hi Rich, The Wolfram answer is correct. http://mathworld.wolfram.com/RamanujanConstant.html There is no code for Wolfram alpha. You just go to their web engine and plug in the expression and it will give you the answer. http://www.wolframalpha.com/ I am not sure that the precedence matters in Rmpfr. Even if it does, the answer you get is still wrong as you showed. Thanks, Ravi -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Thursday, July 02, 2015 6:30 PM To: Aditya Singh Cc: Ravi Varadhan; r-help Subject: Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Ravi 1. You may want to check the sqrt too. 2. Why not take log and try? Aditya -- On Thu 2 Jul, 2015 10:18 AM PDT Boris Steipe wrote: Just a wild guess, but did you check exactly which operations are actually done to high precision? Obviously you will need high-resolution representations of pi and e to get an improved result. B. On Jul 2, 2015, at 10:28 AM, Ravi Varadhan ravi.varad...@jhu.edu wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Ramanujan and the accuracy of floating point computations - using Rmpfr in R
I don't know much about Rmpfr, but it doesn't look like your pi or sqrt or exp are being handled by that package, so I am not really seeing why your result should be more accurate when you have loaded that package. --- Jeff NewmillerThe . . Go Live... DCN:jdnew...@dcn.davis.ca.usBasics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- Sent from my phone. Please excuse my brevity. On July 2, 2015 7:28:19 AM PDT, Ravi Varadhan ravi.varad...@jhu.edu wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Ramanujan and the accuracy of floating point computations - using Rmpfr in R
Just a wild guess, but did you check exactly which operations are actually done to high precision? Obviously you will need high-resolution representations of pi and e to get an improved result. B. On Jul 2, 2015, at 10:28 AM, Ravi Varadhan ravi.varad...@jhu.edu wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
This is the standard FAQ 7.31 and then read in detail the referenced paper. Jim Holtman Data Munger Guru What is the problem that you are trying to solve? Tell me what you want to do, not how you want to do it. On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R
There is a precedence error in your R attempt. You need to convert 163 to 120 bits first, before taking its square root. exp(sqrt(mpfr(163, 120)) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640768333.51635812597335712954 ## just the last four characters to the left of the decimal point. tmp - c(baseR=8256, Wolfram=8744, Rmpfr=8333, wrongRmpfr=7837) tmp-tmp[2] baseRWolfram Rmpfr wrongRmpfr -488 0 -411 -907 You didn't give the Wolfram alpha code you used. There is no way of verifying the correct value from your email. Please check that you didn't have a similar precedence error in that code. Rich On Thu, Jul 2, 2015 at 2:02 PM, Aditya Singh via R-help r-help@r-project.org wrote: Ravi I am a chemical engineer by training. Is there not something like law of corresponding states in numerical analysis? Aditya -- On Thu 2 Jul, 2015 7:28 AM PDT Ravi Varadhan wrote: Hi, Ramanujan supposedly discovered that the number, 163, has this interesting property that exp(sqrt(163)*pi), which is obviously a transcendental number, is real close to an integer (close to 10^(-12)). If I compute this using the Wolfram alpha engine, I get: 262537412640768743.25007259719818568887935385... When I do this in R 3.1.1 (64-bit windows), I get: 262537412640768256. The absolute error between the exact and R's value is 488, with a relative error of about 1.9x10^(-15). In order to replicate Wolfram Alpha, I tried doing this in Rmfpr but I am unable to get accurate results: library(Rmpfr) exp(sqrt(163) * mpfr(pi, 120)) 1 'mpfr' number of precision 120 bits [1] 262537412640767837.08771354274620169031 The above answer is not only inaccurate, but it is actually worse than the answer using the usual double precision. Any thoughts as to what I am doing wrong? Thank you, Ravi [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
