similar to: Precision of values > 53 bits

> On 10 Jan 2013, at 15:56 , S Ellison <S.Ellison at lgcgroup.com> wrote: > > > >> I am working with large numbers and identified that R looses >> precision for such high numbers. > Yes. R uses standard 32-bit double precision. Well, for large values of 32... such as 64. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School

What an impressively zombified thread. Though wondering how 53 bits were supposed to fit into 32 might just warrant revivification. -- Sent from my phone. Please excuse my brevity. On July 20, 2017 5:33:34 AM PDT, peter dalgaard <pdalgd at gmail.com> wrote: > >> On 10 Jan 2013, at 15:56 , S Ellison <S.Ellison at lgcgroup.com> wrote: >> >> >> >>>

Dear R users, I have to calculate gamma functions for negative numbers beyond -171.4. e.x. gamma(-500.4) I got following: > gamma(-170.4) [1] -5.824625e-308 > gamma(-171.4) [1] 0 Warning message: underflow occurred in 'gammafn' I have tried to use a recursion getting values a little futher -180. How could I solve this problem? Thank you beforehand. Chuse.

Hi All, I was wodering if it is possible to increase the precision using R. I ran the script below in R and MAPLE and I got different results when k is large. Any idea how to fix this problem? thanks for your help for (k in 0:2000){ s=0 for(i in 0:k){ s=s+((-1)^i)*3456*(1+i*1/2000)^3000 } } -- View this message in context:

Hi, i try sin, cos, and tan. > sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi) [1] 0.5444181 0.8388140 1.5407532 However, *pi results the following > sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45) [1] 1 0 0 Please try whether the following becomes all right. diff -ruN R-3.3.2.orig/src/nmath/cospi.c R-3.3.2/src/nmath/cospi.c --- R-3.3.2.orig/src/nmath/cospi.c 2016-09-15

hi, my environment... > sessionInfo() R version 3.3.2 (2016-10-31) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Debian GNU/Linux 8 (jessie) locale: [1] LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=C [3] LC_TIME=ja_JP.UTF-8 LC_COLLATE=ja_JP.UTF-8 [5] LC_MONETARY=ja_JP.UTF-8 LC_MESSAGES=ja_JP.UTF-8 [7] LC_PAPER=ja_JP.UTF-8 LC_NAME=C [9] LC_ADDRESS=C

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

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

Given that a number of us are housebound, it might be a good time to try to improve the approximation. It's not an area where I have much expertise, but in looking at the qbeta.c code I see a lot of root-finding, where I do have some background. However, I'm very reluctant to work alone on this, and will ask interested others to email off-list. If there are others, I'll report back.

Despite the need to focus on pbeta, I'm still willing to put in some effort. But I find it really helps to have 2-3 others involved, since the questions back and forth keep matters moving forward. Volunteers? Thanks to Martin for detailed comments. JN On 2020-03-26 10:34 a.m., Martin Maechler wrote: >>>>>> J C Nash >>>>>> on Thu, 26 Mar 2020

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

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 would achieve that an integer is always an

Hi, has someone experience which routine should be used for creating fractional numbers? The two conversion routines deliver different results > x <- (0:7)/7 > MASS::fractions(x) [1] 0 1/7 2/7 3/7 4/7 5/7 6/7 1 > gmp::as.bigq(x) Big Rational ('bigq') object of length 8: [1] 0 2573485501354569/18014398509481984 2573485501354569/9007199254740992 [4]

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

I have been asked (by Roger; thank you for the good question, and I hope it's fine to answer to the public) : > with Pi a sparse matrix and x,y, and ones > compatible n-vectors ? when I do: >> c(t(x) %*% Pi %*% ones, t(ones) %*% Pi %*% y ) > [[1]] 1 x 1 Matrix of class "dgeMatrix" > [,1] [1,] > 0.1338527 >

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) >

All, Martin: Thanks for this and all the other things you are doing to both drive R forward and engage more with the community about things like this. Apologies for missing this discussion the first time it came around and if anything here has already been brought up, but I wonder what exactly you mean when you want recycling behavior. Specifically, based on an unrelated discussion with Henrik