similar to: R-1.7.1 regression test failure on alphaev68-dec-osf5.1

http://bugzilla.mindrot.org/show_bug.cgi?id=812 Summary: alphaev7-dec-osf5.1 cc compiler warning for OpenSSH- 3.8p1 Product: Portable OpenSSH Version: 3.8p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: trivial Priority: P2 Component: Build system AssignedTo:

R-1.7.0 built on NetBSD 1.6, but the validation test suite failed: Machinetype: Intel Pentium III (600 MHz); NetBSD 1.6 (GENERIC) Remote gcc version: gcc (GCC) 3.2.2 Remote g++ version: g++ (GCC) 3.2.2 Configure environment: CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib make[5]: Entering directory `/local/build/R-1.7.0/src/library' >>> Building/Updating

Dear R list, I calculated a two-sided p values according to 2*(1-pnorm(8.104474)), which gives 4.440892e-16. However, it appears to be 5.30E-16 by a colleague and 5.2974E-16 from SAS. I tried to get around with mvtnorm package but it turns out to be using pnorm for univariate case. I should have missed some earlier discussions, but for the moment is there any short answer for a higher

Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found

The IEEE floating point standard allows for negative zero, but it's hard to know that you have one in R. One reliable test is to take the reciprocal. For example, > y <- 0 > 1/y [1] Inf > y <- -y > 1/y [1] -Inf The other day I came across one in complex numbers, and it took me a while to figure out that negative zero was what was happening: > x <-

Hello, I am testing Samba 3.0.0 on a Tru64Unix v 5.1b. I compile it with gcc et gnumake. I am able to start it and I can see a share. Until now, I have only one problem: Logs are full of messages like "Error loading module '/usr/local/samba/lib/charset/ISO8859-1.so': dlopen: Can't open needed library: /usr/local/samba/lib/charset/ISO8859-1.so" In fact, I don't find

On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called. > factor(c(complex(real=NaN), complex(imaginary=NaN))) [1] NaN+0i <NA> Levels: NaN+0i Look at <NA> in the result above. Yes, it happens in earlier versions of R, too. On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.

This is an RFC / announcement related to the 2nd part of PR#16885 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16885 about complex NA's. The (somewhat rare) incompatibility in R's 3.3.0 match() behavior for the case of complex numbers with NA & NaN's {which has been fixed for R 3.3.0 patched in the mean time} triggered some more comprehensive "research". I

That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind. On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,

Hi, I tried to install SAMBA on solaris, typed in command "./configure" in the source directory, but reply the message like below: # ./configure loading cache ./config.cache checking for gcc... no checking for cc... no configure: error: no acceptable cc found in $PATH Would be appreciate if somebody can help me. Regards. __________________________________________________ Do

For a while I have been getting that the complex tests fails on RHEL 6. The specific issue has to do with tanh (see below for full output from complex.Rout.fail). This is both with the stock compiler (GCC 4.4.7) and a compiler supplied through the conda project (GCC 4.8.5). The compiler supplied through conda ends up linking R to certain system files, so the binary is not completely independent

I think Herv?'s idea was just that if switch can evaluate arguments selectively, so can stopifnot(). But switch() is .Primitive, so does it from C. I think it is almost a no-brainer to implement a sequential stopifnot if dropping to C code is allowed. In R it gets trickier, but how about this: Stopifnot <- function(...) { n <- length(match.call()) - 1 for (i in 1:n) { nm

[R 1.7.1 on Windows XP Pro] Since R allows missing values for character variables, why are NA's not propagated by character manipulation functions? For example: > temp <- c("a", NA) > temp [1] "a" NA > is.na(temp) [1] FALSE TRUE > paste(temp[1], temp[2]) [1] "a NA" > substr(temp, 1, 1) [1] "a" "N" >

>From https://github.com/HenrikBengtsson/Wishlist-for-R/issues/70 : ... and follow up note from 2018-03-15: Ouch... in R-devel, stopifnot() has become yet 4-5 times slower; ... which is due to a complete rewrite using tryCatch() and withCallingHandlers(). >From https://stat.ethz.ch/pipermail/r-devel/2017-May/074256.html , it seems that 'tryCatch' was used to avoid the following

Thanks. I assume there is no way to control this via. environment variables or configure settings? Obviously that would be great for something like this which affects tests and seems to be a known problem for older C standard libraries. Best, Kasper On Thu, May 4, 2017 at 9:12 AM, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > As a quick fix, you can undefine HAVE_CTANH

This is getting pretty convoluted. The current behavior is consistent with the description at the top of the help page -- it does not promise to stop evaluation once the first non-TRUE is found. That seems OK to me -- if you want sequencing you can use stopifnot(A) stopifnot(B) or stopifnot(A && B) I could see an argument for a change that in the multiple argumetn case reports _all_

switch(i, ...) extracts 'i'-th argument in '...'. It is like eval(as.name(paste0("..", i))) . Just mentioning other things: - For 'n', n <- nargs() can be used. - sys.call() can be used in place of match.call() . --------------------------- >>>>> peter dalgaard <pdalgd at gmail.com> >>>>> on Mon, 15 May 2017 16:28:42

>>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 15 May 2017 16:54:46 -0700 writes: > Hi, > On 05/15/2017 10:41 AM, luke-tierney at uiowa.edu wrote: >> This is getting pretty convoluted. >> >> The current behavior is consistent with the description at the top of >> the help page -- it does not

I am using a variant of stopifnot a lot. can I suggest that base R extends its functionality? I know how to do this for myself. this is a suggestion for beginners and students. I don't think it would break anything. first, I think it would be more useful if it had an optional character string, so users could write stopifnot( is.matrix(m), "m is not a matrix" ) this would

I believe the performance of isUnsorted() in sort.c could be improved by calling REAL() once (outside of the for loop), rather than calling it twice inside the loop. As an aside, it is implemented in the faster way in doSort() (sort.c line 401). The example below shows the performance improvement for a vectors of double of moving REAL() outside the for loop. # example as implemented in