similar to: Very small numbers in hexadecimal notation parsed as zero

>>>>> Florent Angly <florent.angly at gmail.com> >>>>> on Tue, 20 Dec 2016 13:26:36 +0100 writes: > Hi all, > I have noticed incorrect parsing of very small hexadecimal numbers > like "0x1.00000000d0000p-987". Such a hexadecimal representation can > can be produced by sprintf() using the %a flag. The return value is

Hi all, I believe there is an issue with passing NULL to the function I(). class(NULL) # "NULL" (as expected) print(NULL) # NULL (as expected) is.null(NULL) # TRUE (as expected) According to the documentation I() should return a copy of its input with class "AsIs" preprended: class(I(NULL)) # "AsIs" (as expected) print(I(NULL)) # list() (not expected!

In addition, signed zeroes only exist for floating point numbers - the bit patterns for as.integer(0) and as.integer(-0) are identical. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Jan 26, 2017 at 1:53 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Florent Angly <florent.angly at gmail.com> >>>>>> on Wed, 25 Jan 2017

While implementing R's new 'altrep' functionality in the TERR engine, I discovered a bug in R's 'deferred_string' altrep object: it is not using the correct value of the 'OutDec' option when it expands a deferred_string. See the following example: R 3.5.1: (same results in R 3.6.0 devel engine built 10/5) > options(scipen=0, OutDec=".") >

Hi all, The documentation for head() and tail() describes the behavior of these generic functions when n is strictly positive (n > 0) and strictly negative (n < 0). How these functions work when given a zero value is not defined. Both GNU command-line utilities head and tail behave differently with +0 and -0: http://man7.org/linux/man-pages/man1/head.1.html

I stumbled onto this working on an update to coxph. The last 6 lines below are the question, the rest create a test data set. tmt585% R R version 2.12.2 (2011-02-25) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-unknown-linux-gnu (64-bit) # Lines of code from survival/tests/singtest.R > library(survival) Loading required package: splines

Hi, I am trying to use the gettext() function to translate some text. I have never used this function before, so, it's entirely possible that I am doing something wrong. The issue that I am encountering is that gettext() properly translates some text, but not some other. Natural language was compiled in my R (installed from the Debian repositories): $ R R version 2.15.1 (2012-06-22) --

Hi, I am trying to use the gettext() function to translate some text. I have never used this function before, so, it's entirely possible that I am doing something wrong. The issue that I am encountering is that gettext() properly translates some text, but not some other. Natural language was compiled in my R (installed from the Debian repositories): $ R R version 2.15.1 (2012-06-22) --

Hi all, I am dealing with very large numbers but I am only interested in their last digits. > 244^244 [1] Inf As far as I can tell, the largest number R can take has 308 digits (1+E308). Is there a way I could see the last digits only of 244^244? Many thanks for your help. Vincent Deluard, CFA. -- View this message in context:

Hi all, llvm-test fails on me in the first test (and many subsequent tests, but I hope that fixing the first test will allow me to continue). I see syntax errors from the C compiler and core dumps from llc. Is any of this supposed to happen? This is still on my amd64 machine. However, the build process is using the right incantation to compile (gcc-4.2 -m32 -Wl,-melf_i386). The llvm-gcc

Hi all, We are using compiler-rt for floating point emulation on our DSP core. I am currently investigating two issues found by running TestFloat [1] on our core. The first issue is in __truncdfsf2. __truncdfsf2(0x1p+128) produces 0x1p-128, while the expected result is inf. __truncdfsf2(-0x1p+128) produces -0x1p-128, while the expected result is -inf. I think the condition of the else if on line

Full_Name: Jerry W. Lewis Version: 2.6.1 OS: Windows XP Professional Submission from: (NULL) (24.147.191.250) pchisq(0,0,ncp=lambda) returns 0 instead of exp(-lambda/2) pchisq(x,0,ncp=lambda) returns NaN instead of exp(-lambda/2)*(1 + SUM_{r=0}^infty ((lambda/2)^r / r!) pchisq(x, df + 2r)) qchisq(.7,0,ncp=1) returns 1.712252 instead of 0.701297103 qchisq(exp(-1/2),0,ncp=1) returns 1.238938

The Intel compiled version also fails the below test: > ###------------ Very big and very small > umach <- unlist(.Machine)[paste("double.x", c("min","max"), sep='')] > xmin <- umach[1] > xmax <- umach[2] > tx <- unique(outer(-1:1,c(.1,1e-3,1e-7)))# 7 values (out of 9) > tx <- unique(sort(c(outer(umach,1+tx))))# 11 values

The original report was that compiling with gcc2.95.2 gcc and the related g77 on Irix 6.,5.13 produced an R which wailed its tests with: >> On entry to DGEMM parameter number 1 had an illegal value To some extend this confused me, as the source only seems to mention DGEMM in lowercase. Eventually, after the debug code I added did nothing, I realized that the R which was build was not

I'm still trying to install R on my Irix machine. Now I have a new problem that crops up during the checks. I've found the root cause, and it's that R is returning zero for certain things for reasons I don't understand. 2.225073859e-308, entered directly into R, responds "2.225074e-308". 2.225073858e-308 responds "0". Their negative values respond

I'm still trying to install R on my Irix machine. Now I have a new problem that crops up during the checks. I've found the root cause, and it's that R is returning zero for certain things for reasons I don't understand. 2.225073859e-308, entered directly into R, responds "2.225074e-308". 2.225073858e-308 responds "0". Their negative values respond

2017-06-22 19:49 GMT+02:00 Uwe Ligges <ligges at statistik.tu-dortmund.de>: > On 22.06.2017 17:11, Bernd Funovits wrote: >> >> Hello, >> >> I experienced some unexpected behaviour while determining the rank of matrices (sometimes 1x1 matrices): >> base::qr(matrix(1e-20))$rank returns 1 (incorrect) >> base::qr(diag(c(1, 1e-20)))$rank returns 2

>>>>> Florent Angly <florent.angly at gmail.com> >>>>> on Tue, 20 Dec 2016 13:42:37 +0100 writes: > Hi all, > I believe there is an issue with passing NULL to the function I(). > class(NULL) # "NULL" (as expected) > print(NULL) # NULL (as expected) > is.null(NULL) # TRUE (as expected) > According

>>>>> Florent Angly <florent.angly at gmail.com> >>>>> on Wed, 25 Jan 2017 16:31:45 +0100 writes: > Hi all, > The documentation for head() and tail() describes the behavior of > these generic functions when n is strictly positive (n > 0) and > strictly negative (n < 0). How these functions work when given a zero >

Hello, I experienced some unexpected behaviour while determining the rank of matrices (sometimes 1x1 matrices): base::qr(matrix(1e-20))$rank returns 1 (incorrect) base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect) Best regards, Bernd > R.version _ platform x86_64-w64-mingw32 arch x86_64 os mingw32 system x86_64, mingw32 status major