search for: rcomplex

...ers. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition for > Rcomplex. Then, our downstream code that uses that bindgen-generated > code caused rustc compiler errors such as: > |error[E0560]: union `libR_sys::Rcomplex` has no field named `r` --> > extendr-api\src\robj\into_robj.rs:93:20 | 93 | Rcomplex { r: 0., i: 0. > } | ^ `libR_sys::Rcomplex` doe...

o `Rcomplex' is preferred to `complex' (a future reserved word in C) for R complex objects passed to C. I'm a bit confused here. Is "complex" or "Rcomplex" the future reserved word in C (I thought "complex" already was, but I'm not a C programmer) and is t...

On 4/3/23 14:07, Michael Milton wrote: > Hi all, > > There seems to have been a breaking change in the R trunk caused by a fix > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that > relates to the layout of the Rcomplex typedef. Previously it was a struct, > but now it's a union by default > <https://github.com/r-devel/r-svn/commit/862f9f816ff3ff3cb3f851603f19e99f60a98475#diff-e9b09a44d9dc69444eca2300325e790a0cc6d2c8c3960f47519c7f8ef896f9e4>, > which breaks downstream code that relied on this la...

...to Rust users. The > reason being that we encountered this issue in extendr: a Rust extension > library for R. The specific compiler errors we encounter happen because > bindgen (the Rust code generation library) read the changed R header files, > and generated a new type definition for Rcomplex. Then, our downstream code > that uses that bindgen-generated code caused rustc compiler errors such as: > > error[E0560]: union `libR_sys::Rcomplex` has no field named `r` > --> extendr-api\src\robj\into_robj.rs:93:20 > | > 93 | Rcomplex { r: 0., i: 0. } > |...

Hello, I am trying to call the BLAS Level1 function zdotc from R via a .C call like this: #include "R.h" #include "R_ext/BLAS.h" void testzdotc() { Rcomplex zx[3], zy[3], ret_val; zx[0].r = 1.0; zx[0].i = 0.0; zx[1].r = 2.0; zx[0].i = 0.0; zx[2].r = 3.0; zx[0].i = 0.0; zy[0].r = 1.0; zy[0].i = 0.0; zy[1].r = 2.0; zy[0].i = 0.0; zy[2].r = 3.0; zy[0].i = 0.0; int n=3, incx=1, incy=1; F77_CALL(zdotc)(&ret_val, &n...

...that we encountered this issue in extendr: a >> Rust extension library for R. The specific compiler errors we >> encounter happen because bindgen (the Rust code generation >> library) read the changed R header files, and generated a new >> type definition for Rcomplex. Then, our downstream code that uses >> that bindgen-generated code caused rustc compiler errors such as: >> |error[E0560]: union `libR_sys::Rcomplex` has no field named `r` >> --> extendr-api\src\robj\into_robj.rs:93:20 | 93 | Rcomplex { r: >> 0., i: 0. }...

Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by default <https://github.com/r-devel/r-svn/commit/862f9f816ff3ff3cb3f851603f19e99f60a98475#diff-e9b09a44d9dc69444eca2300325e790a0cc6d2c8c3960f47519c7f8ef896f9e4>, which breaks downstream code that relied on this layout. I'm a...

...l here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here since that would break the C API. Can I ask, would it make sense for us to hard code in R_LEGACY_RCOMPLEX so that Rust can just ignore the union? Because as I understand the only compiler that actually needs to "see" the union is gfortran, and if we pretend it's still a struct in Rust everything should work as before, no? Is this guaranteed to be a stable macro? On Tue, Apr 4, 2023 at 5:...

On Tue, 4 Apr 2023 09:31:33 +0200 Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > it also matters how Rust can handle anonymous nested structures, or > what is the right mapping of the involved C types to Rust It's worth mentioning that Rust's RFC 2102 [1] defines unnamed structs and unions for the purpose of C interoperability, but it's not yet implemented. Would

...(1) = x(1)*x(2) + x(3) end ----<cftest.c>------------------------------------ #include <math.h> #define HAVE_F77_UNDERSCORE 1 #ifdef HAVE_F77_UNDERSCORE # define F77_SYMBOL(x) x ## _ #else # define F77_SYMBOL(x) x #endif typedef struct { double r; double i; } Rcomplex; extern void F77_SYMBOL(cftest)(Rcomplex *x); int main () { Rcomplex z[3]; z[0].r = 3.14159265; z[0].i = 2.172; z[1].i = 3.14159265; z[1].r = 2.172; z[2].r = 123.456; z[2].i = 0.123456; F77_SYMBOL(cftest)(z); printf("%f %f\n", z[0].r, z[0].i); pr...

...7.164) When the imaginary part of the argument is very large, the complex tangent function returns 0+NaNi. For example, tan(1+1000i)=0+NaNi; it should be 0+1i Easy to fix in complex.c, as the original NaN came from division of sinh and cosh that had reached machine infinity. static void z_tan(Rcomplex *r, Rcomplex *z) { double x2, y2, den; x2 = 2.0 * z->r; y2 = 2.0 * z->i; den = cos(x2) + cosh(y2); r->r = sin(x2)/den; /* any limit above about log(DBL_EPSILON) will do */ if (fabs(r->i) < 40.0) r->i = sinh(y2)/den; else r->i = 1.0;...

.... > 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 && (d->opts & DIGITS16)) { Rcomplex z = COMPLEX(vector)[i]; if (R_FINITE(z.r) && R_FINITE(z.i)) { snprintf(hex, 64, "%.17g + %17gi", z.r, z.i); strp = hex; } else strp = EncodeElement(vector, i, quote, '.'); } I think this is a small bug, and that "%17gi" in the snprintf cal...

Hi the following gave me a shock: > atan(2) [1] 1.107149 > atan(2+0i) [1] -0.4636476+0i > or, perhaps more of a gotcha: > atan(1.0001+0i) [1] -0.7853482+0i > atan(0.9999+0i) [1] 0.7853482+0i > evidently atan()'s branch cuts aren't where I thought they were. Where do I look for documentation on this? -- Robin Hankin Uncertainty Analyst National

...iliar with sections 5.2 and 5.6 of the "Writing R Extension" manual plus chapter 6 of Venables and Ripley (2000) S Programming (Springer). From these, I get the following: R storage mode C type logical int * integer int * double double * complex Rcomplex * character char ** raw unsigned char * list SEXP * R object SEXP "integer" and "int" are 32 bits. If I understand correctly, "short" has only 16 bits = 2 bytes. Should I define any "short" vector in...

...link to zlib) and incorrect results in RJaCGH (which contains a copy of zlib). There may well be other problems .... 2) Fedora 14 uses gcc 4.5.1. With CFLAGS containing the default -O2 or higher, HAVE_C99_COMPLEX was detected as false because there is a (genuine) incompatibility between types Rcomplex and C99's double complex. This means that R's fallback code is used, and regretably that contains a serious bug in an 'optimization' by a colleague, so z^n is incorrect for most complex z and integer n (and has been since 2.10.0). The remedy is to use R-patched or R-devel, or...

Dear all, According to CHANGES IN R 3.0.0: o diag() as used to generate a diagonal matrix has been re-written in C for speed and less memory usage. It now forces the result to be numeric in the case diag(x) since it is said to have 'zero off-diagonal entries'. diag(x) does not work for character vector in R 3.0.0 any more. For example, v <- c("a",

Wikipedia claims that C ints are still only guaranteed to be at least 16 bits, and longs are at least 32 bits. So no, R's integers are long. -pd > On 16 Jun 2017, at 20:20 , William Dunlap via R-devel <r-devel at r-project.org> wrote: > > But R "integers" are C "ints", as opposed to S "integers", which are C > "long ints". (I

...17 at 3:01 PM, William Dunlap via R-devel < r-devel at r-project.org> wrote: > "Writing R Extensions" says "int": > > R storage mode C type FORTRAN type > logical int* INTEGER > integer int* INTEGER > double double* DOUBLE PRECISION > complex Rcomplex* DOUBLE COMPLEX > character char** CHARACTER*255 > raw unsigned char* none > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Fri, Jun 16, 2017 at 11:53 AM, peter dalgaard <pdalgd at gmail.com> wrote: > > > > Wikipedia claims that C ints are s...

...arn) { int w, d, e; formatReal(&x, 1, &w, &d, &e, 0); if (ISNA(x)) return NA_STRING; - else return mkChar(EncodeReal(x, w, d, e, OutDec)); + else return mkChar(elim_trailing(EncodeReal(x, w, d, e, OutDec), OutDec)); } SEXP attribute_hidden StringFromComplex(Rcomplex x, int *warn)

"Writing R Extensions" says "int": R storage mode C type FORTRAN type logical int* INTEGER integer int* INTEGER double double* DOUBLE PRECISION complex Rcomplex* DOUBLE COMPLEX character char** CHARACTER*255 raw unsigned char* none Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Jun 16, 2017 at 11:53 AM, peter dalgaard <pdalgd at gmail.com> wrote: > > Wikipedia claims that C ints are still only guaranteed to be at least 16 bits, and...