Hey There!
I'm working with some huge data values and all roads have pointed me to the package Rmpfr. The package relies on the GMP library to allow the use of arbitrarily large numbers. However, I'm having some issues as the package seems map "large" values to another value based on the precision of the initial value. Here are some simplified examples to demonstrate the issue:
Runs as Expected (returned value = input value)
mpfr(8888588858885888,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 8.888588858885888e+15
mpfr(4949494949494949,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.949494949494949e+15
Not Run as Expected (Chooses value based on 1) digit after 16th and 2) how many digits after 16th)
mpfr(49494949494949490,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.9494949494949488e+16
mpfr(4949494949494949000,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.949494949494948864e+18
mpfr(4949494949494949888,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.949494949494949888e+18
mpfr(4949494949494949444,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.949494949494949888e+18
mpfr(4949494949494949333,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.949494949494948864e+18
mpfr(4949494949494949111,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 4.949494949494948864e+18
I also tested this package's utilities out on some hexidecimals:
hex <- "0xfe5b64749cdd0a9834badcf852e7c99f53eb773ec24365853fb03356101928fb"
mpfr(Rmpfr::asNumeric(hex),10000)
#>115048939941552632549260648248461595656614636984310649728136178763075311108096
instead of the correct value of
#>115048939941552636718549134770578535145361984022186965092538353455649250683131.
Thoughts?
Hi, and welcome!
Please see the FAQ: What's a reproducible example (`reprex`) and how do I create one? Using a reprex, complete with representative data will attract quicker and more answers. That will reduce community reverse engineering desire disorder. 
For the decimal question, I think the function is returning what it is supposed to, which is a precision of 1000 bits, not 1000 bytes representing digits.
suppressPackageStartupMessages(library(Rmpfr))
mpfr(pi,1000)
#> 1 'mpfr' number of precision 1000 bits
#> [1] 3.141592653589793115997963468544185161590576171875
Created on 2020-04-08 by the reprex package (v0.3.0)
For the second, I think you want to use
suppressPackageStartupMessages(library(Rmpfr))
mpfr("7f2d36a2a0007f2d36a2a0007f2d36a2a0007f2d36a2a000", base=16)
#> 1 'mpfr' number of precision 192 bits
#> [1] 3118361524223520784583964884878580812558070356334996529152
Created on 2020-04-08 by the reprex package (v0.3.0)
(Didn't have time to take it out to 10K on my puny Airbook)
1 Like
Thanks so much! You're the best and I'll make sure my next post follows those guidelines!
1 Like
I have one follow up comment/question. I previously thought that first function of pi was sound, but after taking a second look (not in the middle of the night my time) I noticed that that output actually differs from that on Wolfram Alpha and what you would get if you used the const function.
suppressPackageStartupMessages(library(Rmpfr))
mpfr(pi,1000)
#> 1 'mpfr' number of precision 168 bits
#> [1] 3.141592653589793238462643383279502884197169399375101
Any thoughts?
1 Like
Have to confess being clueless about the underlying algorithm questions.
About the best I can offer is the introductory paper describing the implementation.
No problem - Thanks for the reply! My last message was supposed to have the following code as well. Working out the kinks...
Rmpfr::Const("pi", prec = 300)
#> 1 'mpfr' number of precision 300 bits
#>[1] 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348248
1 Like
Ah! Thanks for the tip. Please mark your answer as the solution for the benefit of those to follow. n