similar to: Solaris10/amd64 + SunSutio Compile (PR#7767)

Yes, that looks like a bug and an easily fixable one too. However, I spy another issue: Why do we check the !R_FINITE(x) && mu == x before checking for sd < 0 ? The difference is whether we return ML_NAN; or ML_ERR_return_NAN; but surely negative sd should always be an error? I'd be inclined to do if (sigma < 0) ML_ERR_return_NAN; if(!R_FINITE(sigma)) return R_D__0;

Hi, Apropos of a recent Inf question, I've previously wondered if dnorm "does the right thing" with dnorm(0, 0, -Inf) which gives zero. Should that be zero or NaN (or NA)? The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0 is TRUE, then... is this a bug? Thank you, Stephen Rochester, MN USA

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

>>>>> peter dalgaard >>>>> on Sun, 8 Dec 2019 12:11:50 +0100 writes: > Yes, that looks like a bug and an easily fixable one too. agreed. > However, I spy another issue: Why do we check the > !R_FINITE(x) && mu == x before checking for sd < 0 ? The > difference is whether we > return ML_NAN; or ML_ERR_return_NAN;

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

Full_Name: Mikael Weigelt Version: 2.0 OS: windows Submission from: (NULL) (207.171.180.101) The calculation of the qpois attempts to use the Cornish-Fisher expansion as a starting approximation. The definition of the expansion is incorrect. However, since this approximation just gives an initial solution, the end result of the function is still correct. To fix the approximation, in the

Full_Name: Morten Welinder Version: 2.1.0 OS: src only Submission from: (NULL) (216.223.241.212) Now that pcauchy has been fixed, it is becoming clear that qcauchy suffers from the same problems. qcauchy(pcauchy(1e100,0,1,FALSE,TRUE),0,1,FALSE,TRUE) should yield 1e100 back, but I get 1.633178e+16. The code below does much better. Notes: 1. p need not be finite. -Inf is ok in the log_p

Dear R developers, I noticed that core R distribution functions return NaN, when parameter values are out of parameter space. I have looked in source code and found that warnings and return of NaN are done internally in C code. For dgamma.c the line 49 is: if (shape <= 0 || scale <= 0) ML_ERR_return_NAN; OK. How should this be implemented if distribution functions are written

Howdy! Has anybody successfully installed R under OpenBSD? I just tried to install the latest R-release under OpenBSD 2.7 and got the following errors in the make step: pnorm.c:62 'ML_ERR_return_NAN' undeclared pnorm.c:62 'ML_NAN' undeclared pnorm.c:62 'ML_NEGINF' undeclared --Ragnar -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help

Howdy! Has anybody successfully installed R under OpenBSD? I just tried to install the latest R-release under OpenBSD 2.7 and got the following errors in the make step: pnorm.c:62 'ML_ERR_return_NAN' undeclared pnorm.c:62 'ML_NAN' undeclared pnorm.c:62 'ML_NEGINF' undeclared --Ragnar -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help

Good question, I cannot speak for R's developers but I would like to provide some information on the problem. Here are the first few lines of the dnorm function located at src\nmath\dnorm.c: ``` double dnorm4(double x, double mu, double sigma, int give_log) { #ifdef IEEE_754 if (ISNAN(x) || ISNAN(mu) || ISNAN(sigma)) return x + mu + sigma; #endif if(!R_FINITE(sigma)) return R_D__0;

Well, For this particular use case why not just transform the parameters at the R level and then call the existing function? Is there not a closed form mapping? ~G On Jul 1, 2016 2:50 PM, "Joshua Ulrich" <josh.m.ulrich at gmail.com> wrote: > On Fri, Jul 1, 2016 at 6:13 AM, Luis Usier > <luis.henrique.usier at gmail.com> wrote: > > Gabriel, > > > >

Full_Name: Albrecht Gebhardt Version: 0.65.0 OS: Digital Unix 4.0E Submission from: (NULL) (212.17.104.62) Plottimg on the Alpha stopped working with 0.65.0. The tickmarks have a length of -Inf and go across the whole plot. A first solution is the following patch: --- src/main/plot.c.alpha-patch Mon Sep 13 01:37:11 1999 +++ src/main/plot.c Mon Sep 13 01:58:16 1999 @@ -832,7 +832,7 @@

In my package 'glmmML' I'm using old C code and linpack in the optimizing procedure. Specifically, one part of the code looks like this: F77_CALL(dpoco)(*hessian, &bdim, &bdim, &rcond, work, info); if (*info == 0){ F77_CALL(dpodi)(*hessian, &bdim, &bdim, det, &job); ........ This usually works OK, but with an ill-conditioned data

> > On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > > > In my package 'glmmML' I'm using old C code and linpack in the optimizing procedure. Specifically, one part of the code looks like this: > > > > F77_CALL(dpoco)(*hessian, &bdim, &bdim, &rcond, work, info); > > if (*info == 0){ > >

The nice new log=TRUE option in dpois appears to mess up the case where lambda=0 (I was trying to calculate the likelihood of a saturated model). Because the behavior is now always to calculate the probability in terms of exp(log(prob)), there's a test for lambda<=0 which really needs to be only lambda<0. dpois(0:5,0) ought to give 1 0 0 0 0 but gives NaNs instead. Here's

Hi, I've written some C code for density evaluation of the non-central t distribution. It works with the R-1.7.1 source code if placed in the src/nmath directory and after appropriate changes are made to Makefiles, to the dt function in src/library/base/R/distn.R etc. I haven't read a lot of R source code so it may need some R-ification, but I've tried to use the dt.c file as a

Dear testers, 5.0.0-rc3 was just tagged. This is a release candidate in the real sense: if nothing bad comes up in testing, this is what the release is going to look like. Please build, test and upload binaries to the sftp (use the /data/testers-uploads/ directory) and let me know what issues remain. I know we're a little bit behind schedule, but hopefully we can get to 'final'

EVMS Enterprise Volume Management System sounds interesting, looks like it supported CentOS4, but not CentOS5. But maybe I'm not looking in the right places. -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20080607/a5de7c79/attachment-0002.html>

Hi the list, I need to write some efficient distances function, so I read the code for the Euclidean distance. I do not understand the purpose of the line 11 : if x[i] and y[i] are not NA (line 9), can dev be NA ? Christophe #define both_FINITE(a,b) (R_FINITE(a) && R_FINITE(b)) #define both_non_NA(a,b) (!ISNAN(a) && !ISNAN(b)) 1. static double R_euclidean2(double *x, double