similar to: Newbie question on precision

Hi all, why factorial(150) shows the error out of range in 'gammafn'? I have to calculate the number of subset formed by 150 samples taking 10 at a time. How is this possible? best [[alternative HTML version deleted]]

Full_Name: Ben Phalan Version: 2.2.1 OS: Win XP Submission from: (NULL) (131.111.111.231) I have noticed that floor returns the wrong number when there are more than 15 decimal places: > floor(6.999999999999999) [1] 6 > floor(6.9999999999999999) [1] 7 There is a similar problem with ceiling, so this may apply to all/most rounding functions? > ceiling (2.000000000000001) [1] 3 >

Hi, All: Is there a simple way to detect complex conjugates in the roots returned by 'polyroot'? The obvious comparison of each root with the complex conjugate of the next sometimes produces roundoff error, and I don't know how to bound its magnitude: (tst <- polyroot(c(1, -.6, .4))) tst[-1]-Conj(tst[-2]) [1] 3.108624e-15+2.22045e-16i

Hi, I am working with large numbers and identified that R looses precision for such high numbers. The precision is lost exactly when the number is equal or larger than 53 bits. See the following output which shows that the numbers below 53 bit have proper precision: > 2^53 [1] 9007199254740992 > 2^53-1 [1] 9007199254740991 > 2^53-2 [1] 9007199254740990 Now, see the numbers above 53

Hi, Summary: I ran into some unexpected behavior in approx() and tapply() that introduced NA's in "clean" data due to (?) numerical accuracy/round off. The culprit seems to be in match() that coerces it's arguments to character, loosing precision in the process. [R development version 1.2.0, 08 Nov 2000, on Linux] Example: > r > [1] 0.6931472 0.6931472 0.6931472

Hi, Summary: I ran into some unexpected behavior in approx() and tapply() that introduced NA's in "clean" data due to (?) numerical accuracy/round off. The culprit seems to be in match() that coerces it's arguments to character, loosing precision in the process. [R development version 1.2.0, 08 Nov 2000, on Linux] Example: > r > [1] 0.6931472 0.6931472 0.6931472

Hi (If you're wondering, this is a Project Euler question :)) If I wanted to calculate the sum of the digits in the decimal representation of 2^1000, what would be a good way to go about that? I've tried the following methods: # Calculate the sum of digits in the decimal representation of 2^n # Only works for smaller values of n bsum <- function(n) { s <- 0 e <-

Hi, I wanted to download a file and did the following: --------------------------------------------------------- > fileLink <- 'ftp://ftp.ncbi.nih.gov/pub/geo/DATA/supplementary/series/GSE1000/GSE1000_RAW.tar' > download.file(fileLink,'/geoDat') trying URL 'ftp://ftp.ncbi.nih.gov/pub/geo/DATA/supplementary/series/GSE1000/GSE1000_RAW.tar' ftp data connection made,

Hello I've been looking to LLVM, in order to develop a compiler for a cryptography oriented language. I started by following the tutorials on Kaleidoscope, and I must say they were very usefull. Now I need to use GMP, so i can add Big Integer support. I am trying to change Kaleidoscope to support BigIntegers instead of doubles, but I don't really know how to do that. I'd really

Hi, I had a function that looked like: diff <- lm(x ~ y + z) How can I pass the argument to the 'lm' function on the fly? E.g., if I pass it in as a string (e.g. "x ~ y + z"), then the lm function treats it as a string and not a proper argument. many thanks [[alternative HTML version deleted]]

Hi, I work with bio-conductor, but this is probably a basic R question. I want to emulate the GOBPOFFSPRING$"GO:0008150" command: > allBP <- GOBPOFFSPRING$"GO:0008150" > class(allBP) [1] "character" > length(allBP) [1] 16066 > I want to create a function so that I can execute the command by passing as a parameter the portion in quotes in the above

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

As ever, I learn from this: I didn't know apt-file. Got it, installed it, used it: root at DebianAdvent:/home/chris/Downloads/gmp-6.1.2# apt-file search jni.h android-libnativehelper-dev: /usr/include/android/nativehelper/jni.h android-platform-frameworks-native-headers: /usr/include/android/android/asset_manager_jni.h android-platform-frameworks-native-headers:

I've recently installed Ubuntu 5.10 on a desktop and need R installed, however, even after uncommenting the repos associated with universe, backports and multiverse, the packages available for Ubuntu are somewhat out of date: clint at simba:~$ apt-cache policy r-base r-base-core r-base: Installed: (none) Candidate: 2.1.1-1 Version table: 2.1.1-1 0 500

I've recently installed Ubuntu 5.10 on a desktop and need R installed, however, even after uncommenting the repos associated with universe, backports and multiverse, the packages available for Ubuntu are somewhat out of date: clint at simba:~$ apt-cache policy r-base r-base-core r-base: Installed: (none) Candidate: 2.1.1-1 Version table: 2.1.1-1 0 500

I should have formulated my question in a more specific way. 1. I suspect this is a floating point precision issue. I am not very knowledgeable about R internals, can someone else confirm it? 2. Should this be considered a bug or not, because it is "just a precision issue"? Should I report it? 3. How can it happen? From a quick review of ts.R, it looks like the values of the time

Thanks Dirk and Enrico, First clarification: I'm in this mess because I'm trying to run R 3.5.2 within Debian stable (9/"sretch") using the stretch-cran35 repository. That uses and provides r-api-35 but many of the packages depend upon r-api-3. As Johannes said a day or so back, the way around this is to use install.packages() in R to get the packages you want. That leads you

On Fri, 1 Sep 2017, Andrea Altomani wrote: > I should have formulated my question in a more specific way. > > 1. I suspect this is a floating point precision issue. I am not very > knowledgeable about R internals, can someone else confirm it? Yes. If you represent a series with increment 1/12 it depends on how you do it. As a simple example consider the following two descriptions

Hi all, I found a discrepancy between the sum() in R and either a sum done in C or Fortran for vector of just 5 elements. The difference is very small, but this is a very small part of a much larger numerical problem in which first and second derivatives are computed numerically. This is part of a numerical method course I am teaching in which I want to compare speeds of R versus Fortran (We