search for: rmpfr

I've been asked in private, but am answering in public so others can comment / or find this answer in the future after a web search. This is about the package 'Rmpfr' (R interface to MPFR, the GNU C library for arbitrary precise numbers). > How can you build a vector of mpfr numbers sequentially? > Typically I would do something like the following (and try to > replace the for loop with some sort of apply construct) > > vec <- NULL >...

Hello everyone, R beginner, I am confronted with the need to use Rmpf. In my first scripts I made use of X=read.table(file.choose(), header=FALSE, sep=",",dec=".") X=as.matrix(X) to load into a matrix data from file before matrix use. How can I do to load the same data in a "mpfrMatrix". Is it possible to use with "mpfrMatrix" the same as operations

...iled > working of the function whose zero(s) are sought, i.e., pbeta() > > > Ben: Do you have an idea of parameter region where approximation is poor? > > I think that it would be smart to focus on that to start with. > > ---------------------------- > > Rmpfr matrix-/vector - products: > > > Martin: On a separate precision matter, did you get my query early in year about double > > length accumulation of inner products of vectors in Rmpfr? R-help more or > > less implied that Rmpfr does NOT use extra length. I've b...

...'ll report back. Ben: Do you have an idea of parameter region where approximation is poor? I think that it would be smart to focus on that to start with. Martin: On a separate precision matter, did you get my query early in year about double length accumulation of inner products of vectors in Rmpfr? R-help more or less implied that Rmpfr does NOT use extra length. I've been using David Smith's FM Fortran where the DOT_PRODUCT does use double length, but it would be nice to have that in R. My attempts to find "easy" workarounds have not been successful, but I'll admit tha...

...ING May/June 2010; http://perso.ens-lyon.fr/philippe.theveny/cise.pdf): d = 173746a + 94228b ? 78487c where: a = sin(1022), b = log(17.1), and c = exp(0.42). Ghazi et al. report: d = ?1.341818958e?12 whit IEEE-754 quadruple precision (113 bits). I have tried to reproduce such result using the Rmpfr library using: a <- mpfr(sin(10^22), 230) b <- mpfr(log(171/10), 230) c <- mpfr(exp(42/100), 230) (d <- 173746*a + 94228*b - 78487*c) 1 'mpfr' number of precision 230 bits [1] 2.9904079212883516447618603706359863281250000000000000000000000000000000e-11 Which does not corr...

Dear Team, Maybe somebody already tried to install mpfr and gsl packages for R on SLES. Exactly I try to install Rmpfr_0.6-1.tar.gz and gsl_1.9-10.3.tar.gz on SLES11 SP4. These are the available packages from official SLES SDK media: rtest:/home/ruser # rpm -qa | grep -i gsl gsl-devel-1.11-1.30 gsl-1.11-1.30 rtest:/home/ruser # As I understand gsl is from 1.11 till 1.30 level. rtest:/home/ruser # rpm -qa...

Thank you Martin for giving to know and developing 'Rmpfr' library for unlimited size integers (GNU C GMP) and arbitrary precision floats (GNU C MPFR): https://cran.r-project.org/package=Rmpfr My question is: In the long term (For R3.7.0 or R3.8.0): Does it have sense that CMP substitutes INTSXP, and MPFR substitutes REALSXP code? With this we woul...

...l be needed crucially depend on the detailed working of the function whose zero(s) are sought, i.e., pbeta() > Ben: Do you have an idea of parameter region where approximation is poor? > I think that it would be smart to focus on that to start with. ---------------------------- Rmpfr matrix-/vector - products: > Martin: On a separate precision matter, did you get my query early in year about double > length accumulation of inner products of vectors in Rmpfr? R-help more or > less implied that Rmpfr does NOT use extra length. I've been using David...

...ill be methods, S3 and S3 and there is often no conflict and no masking at all for all these, so I am claiming that your "statistics" are quite a bit biased, and probably most of the more common names are proper methods. There is another issue, I've wanted to raise, exemplified by my Rmpfr package [interface to the MPFR C library for high-accuracy floating point computations]: As it defines "mpfr"-ified versions of standard R functions many of which are *not* generic, it must mask them. E.g, currently, the following "are masked" messages (when attaching Rmpfr)...

...etailed > working of the function whose zero(s) are sought, i.e., pbeta() > > > Ben: Do you have an idea of parameter region where approximation is poor? > > I think that it would be smart to focus on that to start with. > > ---------------------------- > > Rmpfr matrix-/vector - products: > > > Martin: On a separate precision matter, did you get my query early in year about double > > length accumulation of inner products of vectors in Rmpfr? R-help more or > > less implied that Rmpfr does NOT use extra length. I've be...

Thank you Gabriel for valuable insights on the 64-bit integers topic. In addition, my statement was wrong, as Python3 seems to have unlimited (and variable) size integers. Here is related CPython Code: https://github.com/python/cpython/blob/master/Objects/longobject.c Division between Int-32 and Int-64 seems to only happen in Python2. Best, Juan El mi?rcoles, 29 de mayo de 2019, Gabriel

Are integers strictly a signed 32 bit number on R even if I am running a 64 bit version of R on a x86_64 bit machine? I ask because I have integers stored in a hdf5 file where some of the data is 64 bit integers. When I read that into R using the hdf5 library it seems any integer greater than 2**31 returns NA. Any solutions? Thanks, Theo [[alternative HTML version deleted]]

Are integers strictly a signed 32 bit number on R even if I am running a 64 bit version of R on a x86_64 bit machine? I ask because I have integers stored in a hdf5 file where some of the data is 64 bit integers. When I read that into R using the hdf5 library it seems any integer greater than 2**31 returns NA. Any solutions? Thanks, Theo [[alternative HTML version deleted]]

On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote: > > As I recall, several packages mask the simulate generic in stats, if you > are looking for examples. > FWIW, here is a list of base* functions masked** by CRAN packages: https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md Look at the long table in the end. simulate indeed comes up

Le 18/02/2023 ? 21:44, J C Nash a ?crit?: > I wrote first cut at unirootR for Martin M and he revised and put in > Rmpfr. > > The following extends Ben's example, but adds the unirootR with trace > output. > > c1 <- 4469.822 > c2 <- 572.3413 > f <- function(x) { c1/x - c2/(1-x) }; uniroot(f, c(1e-6, 1)) > uniroot(f, c(1e-6, 1)) > library(Rmpfr) > unirootR(f, c(1e-6, 1), exte...

I wrote first cut at unirootR for Martin M and he revised and put in Rmpfr. The following extends Ben's example, but adds the unirootR with trace output. c1 <- 4469.822 c2 <- 572.3413 f <- function(x) { c1/x - c2/(1-x) }; uniroot(f, c(1e-6, 1)) uniroot(f, c(1e-6, 1)) library(Rmpfr) unirootR(f, c(1e-6, 1), extendInt="no", trace=1) This gives more...

...[[2]] [,1] [,2] [,3] [1,] 1 . . [2,] . 1 . [3,] . . 1 > ---------------------------------------------- BTW, I (and the package users) suffer from exactly the same problem with the "MPFR" (multi precision numbers) provided by my package Rmpfr: > require(Rmpfr) > c(mpfr(3,100), 1/mpfr(7, 80)) ## works fine 2 'mpfr' numbers of precision 80 .. 100 bits [1] 3 0.14285714285714285714285708 > c(pi, 1/mpfr(7, 80)) ## "fails" even worse than in 'Matrix' case [[1]] [1] 3.141593 [[...

...according to its documentation (and I think very much the same as in S and S-PLUS) and has done so for ages. ---- and if you don't agree with 1) -- 4) you may pretend for a moment instead of starting to discuss them thoroughly. Recently, a useR has alerted me to the fact that my Rmpfr's package arbitrary (high) precision numbers don't work for a relatively simple function. As I found the reason was that that simple function used ifelse(.,.,.) and the problem was that the (*simplified*) gist of ifelse(test, yes, no) is test <- as.logical(test) ans <- test a...

I've discovered an infelicity (I guess) in qbeta(): it's not a bug, since there's a clear warning about lack of convergence of the numerical algorithm ("full precision may not have been achieved"). I can work around this, but I'm curious why it happens and whether there's a better workaround -- it doesn't seem to be in a particularly extreme corner of parameter

...less from the class: it "only" needs `c` and `[` to work > > and a mixture of your two proposals would be possible too: > > ans <- c(yes[0], no[0]) > ans <- ans[seq_along(test)] > > which does *not* work for my "mpfr" numbers (CRAN package 'Rmpfr'), > but that's a buglet in the c.mpfr() implementation of my Rmpfr > package... (which has already been fixed in the development version on > R-forge, > https://r-forge.r-project.org/R/?group_id=386) > > > But of course that wouldn't help with fact...