similar to: incorrect xlim error message in image() (PR#1160)

Full_Name: Teru KAMOGASHRIA Version: 2.0.1 OS: SunOS sun 5.10 Generic i86pc i386 i86pc Submission from: (NULL) (219.5.176.24) rbinom.c cannot be compiled because of the casting problem. /opt/SUNWspro/bin/cc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -c rbinom.c -o rbinom.o "rbinom.c", line 60: operand must have real

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

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;

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

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

Vince Carey found this (thank you!). Since the fix to the problem is not entirely obvious, I post this to R-devel as RFC: help(dist) says: >> Missing values are allowed, and are excluded from all computations >> involving the rows within which they occur. If some columns are >> excluded in calculating a Euclidean, Manhattan or Canberra >> distance, the sum is

Full_Name: D Kreil Version: 2.1.1 OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license Submission from: (NULL) (62.178.15.60) During compiliation, I get: ld: Unsatisfied symbol "finite" in file colors.o Fix: replace "finite" with R_FINITE in colors.c line 269. I have, this time, searched through the R-admin.html, but not found a mention. This is all a bit hard for me

> On 10 Feb 2017, at 14:53, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > Thanks to all who answered my third question. I learned something, but: > > On 2017-02-09 17:44, Martin Maechler wrote: >> >>>> On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: >>>> >>>> In my package 'glmmML'

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

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

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

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

If you set the "digits17" control option in deparse, you get a lot of unnecessary space in the representation of complex numbers. > deparse(0 + 0i) [1] "0+0i" > deparse(0 + 0i, control = "digits17") [1] "0 + 0i" As far as I can tell, the logic for this comes from this piece of /src/main/deparse.c: if (TYPEOF(vector) == CPLXSXP

Thanks to all who answered my third question. I learned something, but: On 2017-02-09 17:44, Martin Maechler wrote: > >>> 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:

R-2.9.0/include/R_ext/Arith.h has: int R_IsNA(double); /* True for R's NA only */ int R_IsNaN(double); /* True for special NaN, *not* for NA */ int R_finite(double); /* True if none of NA, NaN, +/-Inf */ #define ISNA(x) R_IsNA(x) /* True for *both* NA and NaN. The first and last lines are contradictory - if R_IsNA is true only for NA, not NaN, then ISNA should be the same.

Canberra distance is defined in function `dist' (standard library `mva') as sum(|x_i - y_i| / |x_i + y_i|) Obviously this is undefined for cases where both x_i and y_i are zeros. Since double zeros are common in many data sets, this is a nuisance. In our field (from which the distance is coming), it is customary to remove double zeros: contribution to distance is zero when both x_i

Canberra distance is defined in function `dist' (standard library `mva') as sum(|x_i - y_i| / |x_i + y_i|) Obviously this is undefined for cases where both x_i and y_i are zeros. Since double zeros are common in many data sets, this is a nuisance. In our field (from which the distance is coming), it is customary to remove double zeros: contribution to distance is zero when both x_i

In the hope of some meaningful response and ignoring the risk of further abuse, let me try to clarify the issue here. I have re-read the 'Writing R Extensions' manual. It seems to me that it clearly says R API functions can be called from from C++ programs, and the API includes the special values ISNAN() and R_FINITE() and the missing test ISNA(). R_FINITE is no problem. It is

Dear all As far as I could trace, looking at the function C function numeric_deriv, this unwanted behavior comes from the inner most loop in, at the very end of the function, for(i = 0, start = 0; i < LENGTH(theta); i++) { for(j = 0; j < LENGTH(VECTOR_ELT(pars, i)); j++, start += LENGTH(ans)) { SEXP ans_del; double origPar, xx, delta; origPar = REAL(VECTOR_ELT(pars, i))[j];